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ABSTRACT 


Information sharing can result in emergent behaviors that affect the safety properties 
associated with overt information flows. Secure cross-domain integration, involving the 
safety properties of both individual domains and the information dissemination aeross 
those domains, can result in leakage of information during the brokering of that 
information in an enterprise-level, multilevel secure (MLS) system using mixed model 
access control. Existing access control models do not address this problem. To address 
this gap, we developed a technique for building eompositional models that combine both 
role-based aecess control and traditional MLS-based Bell-LaPadula models to provide for 
a high-assurance MLS system access controller. However, such compositional models 
introduce information rights proliferation during the specification of high-assurance 
security requirements and the seeurity policy to provide for safety within the system. 
We addressed that problem with a teehnique that leverages RuleML to specify 
declassification policies for securing information exchange between different security 
levels of disparate access control models. The technique supports the tranquility principle 
allowing for desired information flows while not violating the overall security policy of 
the system. We demonstrated the teehnieal feasibility of using both of these techniques, 
using as our example application cross-domain information sharing in conducting 
Maritime Domain Awareness operations. 
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I. INTRODUCTION 


In his testimony to the Senate in February 2008, Vice Admiral John Michael 
McConnell, The Director of National Intelligence, offered: 

The U.S. information infrastructure including telecommunications and 
computer networks and systems, and the data that reside on them is critical 
to virtually every aspect of modern life. Therefore, threats to our IT 
infrastructure are an important focus of the Intelligence Community. As 
government, private sector, and personal activities continue to move to 
networked operations, as our digital systems add ever more capabilities, as 
wireless systems become even more ubiquitous, and as the design, 
manufacture, and service of information technology has moved overseas, 
our vulnerabilities will continue to grow. [1] 


Protecting both the information infrastructure and the processing of data is a critical 
information assurance (lA) concern. Information sharing via an automated information 
system (AIS) requires that the AIS enforce confidentiality, integrity, and availability of 
the security policy! in the applicable domain.^ Enforcing security policy is challenging 
when the data can flow between security domains and the information systems permit 
data at different levels of sensitivity to be accessed and stored on the same set of 
computing nodes. A cross-domain security architecture^ delineates the allowable 
information flows between information systems. Consequently, such an architecture, if 
constructed, would support government and military information systems requiring 
multiple levels of security to support full spectrum operations in the ongoing Long War 
(formerly the Global War on Terror) and to meet the needs of our military and 
government organizations at the highest levels of lA. These multilevel secure systems 

1 A security policy is a set of rules that specify how information and resources are managed, protected, 
and distributed [2]. 

2 A domain is a logical structure of resources or nodes working under the same security policy and 
management [2]. Examples of domains are: (1) a different classification level such as the Secret level (2) a 
separate management group such as the U.S. Army. 

3 Security Architecture is an architecture supporting the primary purpose of fulfilling security 
requirements in accordance with an established security policy to provide a predetermined level of trust 
[3]. 
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require assurances^ that they, in fact, offer protection of data and services between users, 
components and interfaces of varying levels of confidentiality, integrity and availability. 
Intelligence Community Directive (ICD) 503, “Information and Information System 
Governance” establishes the requirements and controls necessary for an information 
system to achieve hierarchically-defined levels of assurance, in addition to outlining the 
process for the certification and accreditation (C&A) of multilevel secure (MLS) systems 
[4], The certification criteria for confidentiality, integrity, and availability to meet the 
updated ICD 503 High-High-High (H-H-H) assurance level have a stringent list of 
requirements for each facet. Developing systems to meet all of the security requirements 
of the policy directives, while also meeting all other types of requirements, is a challenge 
for software and systems engineers. There are two particular access control models in 
commercially available trusted products and DOD systems that will be used as the focus 
for this research: Bell-LaPadula (BLP) and role-based access control (RBAC). 
Information systems utilizing the BLP model are not sufficient to provide the level of 
data granularity and “need to share” capability required within a security domain. Nor is 
RBAC sufficient because it does not readily accommodate access control across multiple 
security domains. What is needed are MLS systems utilizing mixed-model access control, 
combining the features of the BLP and RBAC models to support net-centric enterprise 
services for sharing information [5]. 

One possible solution arose from a U.S. Navy Tactical Exploitation of National 
Capabilities (TENCAP) project named Radiant Alloy. In this type of mixed model access 
control system architecture, the Information Broker (IB) is an integral element. For an 
enterprise-level, service-oriented architecture (SOA)-based, MLS AlS-supporting mixed 
model access control, the IB plays the role of information management controller. The IB 
is the intermediary between the requester of the information and the data repositories. 
The IB provides the data and at the same time protects the anonymity of the source of the 
data. This anonymity is accomplished because the IB is effectively operating as a middle¬ 
man and collecting the data from multiple repositories. Thus, no attribution is linked to a 

4 Assurance is the confidence that an entity meets its security requirements, based on specific evidence 
provided by the application of assurance techniques [3]. 
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particular source for any of the information response. The responsibility of the IB is “to 
facilitate the exchange of data between disparate applications” [6]. The IB is an 
architeetural element that mediates aecess between differing data sources without 
requiring a eustom eonnection, while also enabling the sharing of data between 
information systems, as depicted in Figure 1. 
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Figure 1. Information Broker System Architecture, after [7] 


The IB orehestrates and logs all of the system-level access requests and responses. 
The IB mediates all user-level access requests and serves as a Policy Enforcement Point 
(PEP), if directed to do so by the Policy Decision Point (PDP). The PDP is responsible 
for authorization deeisions, and resides in between the subjects, PEPs and the resource 
managers. The IB requests data through the Trusted Database Conneetor (TDC) and 
corresponding data stores to fulfill user requests. If required by policy, the IB must 
maintain the anonymity of the data origin, and orchestrating the ability of a user to write 
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back to a data store that may be of a lower classification level (so the user cannot infer 
the origin). This involves the replication of the IB service at all sensitivity levels and 
having additional services that allow interaction between the IBs without alerting users 
and without impacting the inviolability of the data. The IB is also accessible from all 
possible platforms and environments, and provides mandatory access control for MLS 
based on a hierarchical, lattice-based access control model [6]. The information broker is 
intended to be a highly trustworthy component of a system, responsible for dealing with a 
myriad of clearances, classifications, and compartments. 

Clearly, the IB is the central service of the system and must rely on the 
orchestration of several other services to fulfill its own role. However, each of these 
functions of the IB must be provided with some level of assurance that it meets the 
security requirements of ICD 503. The specification and management of access control is 
fundamental to the IB role. This role becomes more challenging to perform with the 
added complexity of having mixed access control models. The added complexity of 
relationships necessitates the establishment of guarantees against information leakage 
(non-interference) for a compositional^ access controller. With this type of system, we 
discover a non-compositional property; that is, even if all components would not leak 
information individually, the combination thereof may enable information leakage via 
overt channels. This aspect of safety for mixed access controllers is an essential property 
for cross-domain MLS solutions. This research does not explore the leakage of 
information via covert channels, but rather provides for policy-based prevention of overt 
information flows that compromise the system’s information flows. The term “safety” as 
used here refers to protection provided by a system against leakage of information. 
Formal definitions of safety and other key terms are given in the background section of 
this chapter. 


5 Compositional refers to the combination of disparate access control systems and security policies 
into an aggregated information system. 
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A. STATEMENT OF THE PROBLEM 

Information obtained first, or shared appropriately within an organization, helps 
an enterprise maintain a competitive advantage over adversaries, where real-time data 
feeds and data fusion aid in obtaining information. Other things being equal, information 
supremacy is essential to winning wars when the right information is shared at the right 
time, and the risk of sharing information with the wrong individuals is acceptably low to 
avoid catastrophic consequence [8]. With multiple information sources and the ever- 
increasing volume of data that is generated in real time (or near real time) and stored, 
enabling correlation and extracting information becomes a daunting challenge. The use of 
business intelligence and analytics (BIA) creates an opportunity for a real-time analytical 
engine to scan a broad set of unique data sources, identify common patterns in the data, 
translate those patterns into events, and then correlate and resolve those events to specific 
and actionable information. Traditional approaches to this big data analytic challenge 
have relied on batch retrieval and relational schemas combined into a structured analysis, 
but these do not account for the larger scale requirements of real-time streaming data and 
the correlation to find hidden relationships and useful information from seemingly 
useless data, as is found in a BIA tool. 

The ability to gain superiority, either economically, politically, militarily, or 
otherwise through the processing and fusion of unclassified data and classified data to 
produce usable information that is shared across domains is the key impetus underlying 
the United States’ National Security. For instance. Maritime Domain Awareness (MDA) 
is defined by the U.S. Department of Homeland Security as the 

effective understanding of anything associated with the global maritime 
domain that could impact the United States’ security, safety, economy, or 
environment...MDA is a key component of an active, layered, maritime 
defense-in-depth. Maritime domain awareness will be achieved by 
improving our ability to collect, fuse, analyze, display, and disseminate 
actionable information and intelligence to operational commanders and 
decision makers. [9] 

One arena where timely sharing of information is critical is cross-domain 
integration, which refers to subjects sharing information across two or more security 
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domains. A real-world example of this integration lies with the distribution of 
intelligence indicators related to malware and Advanced Persistent Threat (APT) actors 
in the context of national security. This sharing between government, the defense 
industrial base (DIB), and other industry partners, like Symantec and McAfee, requires a 
cross-domain system to integrate the repositories of each proponent. Secure cross-domain 
integration requires safety of individual domains as well as safety of information 
dissemination across those domains. These domains may be governed by differing access 
control models and different security levels of the same MLS domain. Consequently, 
sharing information between them should be done so that it does not violate safety 
criteria of the access controller that governs the concerned domain and does not create 
covert channels enabling leakage of information. Information dissemination safety must 
work with disparate access controllers as well as varying declassification policies and 
rules between domains. Currently, we have many differing levels of security, but those 
levels are all separate. These systems are traditionally based on the BLP model and do 
not allow for information dissemination across domains. Human declassifiers and sneaker 
nets^ can be used to transfer information between domains; however, these mechanisms 
are inefficient and impractical in today’s highly connected environment hosting time- 
critical applications. Inherent with cross-domain information sharing is the risk of data 
leakage between domains. Each domain employs its own security policies and access 
control model, which can result in uncontrolled observability^ between domains. This 
type of leakage violates information flow policy, as well as the safety of the system 
overall. 

The current architectures using mixed model access controllers between domains 
are not sufficient and the singular examination of domains for safety is also not sufficient. 
The composition of access controllers can result in emergent violations of safety within 


6 Sneaker net refers to a manual work around for the transfer of information between information 
systems, where a user carries some type of physical media with information copied from one system to 
another for input. 

7 Observability refers to the visibility of the results of a change and in this research refers to how 
information in one domain can be inferred or viewed from outside of the domain or from separate 
permission subsets within the domain. 
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or between domains. It is from this lack of safety resulting from the composition of 
access controllers that we realize an information flow and information leakage problem 
that requires a re-architecting of the mixed model access controller to prevent the 
leakage. As a critical element of this re-architecting, we need to integrate an Information 
Declassifier (ID) element into the architecture to handle inconsistencies and emergent 
weaknesses in the security policy that arise from the composition of access control 
models. We must also develop and enforce specific rules and policies for the ID at every 
domain to allow for the desired level of information sharing while still protecting the 
safety of the system and the information flow. We propose using RuleML as a means to 
specify information flow control policies between security domains. Execution RuleML 
[10] specifies Prolog-like rules that use a XML-like syntax, and consequently are 
valuable for use in SOA. By re-architecting the mixed model access controller, and 
specifying the ID policies and rules, we can regain the safety of our information flows 
within the AIS and partially prevent information leakage between domains. 

B. HYPOTHESIS 

RuleML can be used as a policy specification language, based on a UML Use- 
Case analysis that supports mixed model access controllers for a high assurance, MLS, 
SOA-based system, to prevent information leakage and regain safety that is compromised 
by system behaviors that emerge from the composition of two or more different access 
control models. 

This hypothesis will be tested with a proof of concept information broker and 
information declassifier ruleset developed to support the MDA Use-Case scenarios that 
use executable RuleML. The execution trace of the rules will demonstrate the efficacy of 
the IB to redirect information flows using RuleML and prevent information leakage. 

C. BACKGROUND 

Access control systems are expected to provide safety guarantees as the basis for 
trust and the overall assurances in the system. The access controls are responsible for 
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managing all direct accesses to the system resources (objects*) according to the rules and 
assigned by the security policy and the access control model [11]. An access control 
model can be separated into many logical categories: discretionary access control (DAC), 
mandatory access control (MAC), Role-based Access Control Systems (RBAC), 
Attribute-Based Access Control Systems (ABAC), etc. These subject-centric access 
control models provide a framework that dictates how subjects can access^ objects in the 
system. Other systems include capability-based systems, where each object has a list of 
capabilities that are required to be possessed by any user of the object. DAC systems 
allow the user to control access rights to the objects that they own, where this ability to 
change rights is subject to some set of rules, which can change during the course of 
operation of the system. Because of this, it is possible to bypass access restrictions and 
does not provide an assurance for the protection of data in the system. Once the user 
accesses data, the system can no longer control what the user does with the data (e.g., 
copy, move). The discretionary access control model then allows for the transfer or 
propagation of data in violation of the original security policy. Mandatory access control 
policies typically define a set of allowed access rights of subjectsi® to objects within a 
particular domain, and assume that the other objects are not allowed access. MAC 
policies are enforced by the system and not relegated to the user for access. However, 
there are systems specified using prohibitions, where the policy says which subjects are 
prohibited from accessing the resources, and all other subjects are allowed access. In 
MAC systems, subjects within the system are assigned sensitivity labels according to 
their level of trust, and objects are similarly assigned labels according to the level of trust 
that would be required of a subject to access the information in the object. A user is 
bound, during a specific session, to one or more subjects at a defined sensitivity level. 
This binding is constrained by the user’s clearance level and the security level of the 


8 Objects are entities that contain or receive information. 

9 Access is defined as a subject’s ability to perform some action such as read, write, copy, move, 
delete, and execute an object. 

10 Subjects are active entities, generally in the form of a person, program, process, or device that cause 
information to flow among objects, or that change the state of the system. 
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interface or terminal they are using, for the duration of that session. These subject labels 
are compared against that of an object, which the user might want to gain access to; if the 
subject label is equal to or higher than that of the object, the user may access the object. 
MAC models are representative of a MLS system, like a military security system based 
on the Bell-LaPadula model, where objects and subjects are ordered based upon their 
classification levels (Classified, Secret, etc.) and users are granted access to objects based 
on the relationship between the clearance level they possess, and the classification level 
of the object. 

The safety guarantee relates to the aspect of information flow wherein 
information directly refused to a user cannot be indirectly obtained by executing a set of 
operations. Harrison et al. [12] defined authorization systems that allowed the 
modification of access rights, along with the ability for creating and deleting subjects and 
objects within the system. The safety concept introduced in [12] is that that access to an 
object within the system is impossible without the concurrence of the owner of that 
object. Since an owner in a DAC system may extend rights to an object that in turn may 
be given away without the owner’s knowledge, no protection system can be safe by this 
definition. It is shown in [12] that it is generally undecidable whether “given an initial 
access matrix, there is some sequence of commands in which a particular generic right is 
entered at some place in the matrix where it did not exist before.” Given an access matrix 
M and a right r (from a set of rights R), verifying the state of M with respect to r is 
undecidable. An additional aspect of safety that must be addressed for an MLS system is 
leakage from a covert channel. A covert channel utilizes shared resources in a system as a 
path of communication to transfer information. This is an unintended path from the 
original system design, but can be realized as either a storage channel or a timing channel 
[3]. In an information system, the non-existence of a covert channel cannot be proven. 
The amount of information that can be transmitted via a covert channel affects the 
severity of that channel to the security policy. 

Bishop, in [3], defines secure versus safe with respect to the level of abstraction 
and implementation. Secure and non-secure are used to refer to the actual implementation 
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of a system, while safety references the abstract security modebb Under these 
definitions, we can have a secure system that will correspond to an abstract model that is 
safe for all rights, but if we have a safe model, we do not necessarily ensure a secure 
system [3]. Bishop also adds to the definition of safety from [12] and further defines 
information leakage. Fundamental to these concepts is the access control matrix model, 
which is the simplest framework for describing a protection system. An access control 
matrix views a system in terms of the set of protected entities, contained in the set of 
objects O; subjects 5 is a set of active objects, such as users and processes; and the rights 
between subjects and objects drawn from a matrix A, where the set of rights R in each 
entry a[s,o] where s E S, o E O, and a[s,o] c i?. A matrix A, captures entity relationships 
where rights drawn from R get assigned to each entry a[s,o]. The protection states of a 
system are then represented by the triple (S, O, A). Leakage occurs when a generic right r 
E R is added to an element of the access control matrix not already containing r. The set 
of authorized states for the system are those in which no command or set of commands 
c(xi, ..., Xn) can leak r. A system is termed safe with respect to the right r if the system 
can never leak r [3]. Safety as described in [3] is critical for cross-domain solutions 
(CDS). CDS must employ access controls that guarantee safety in order to prevent the 
inadvertent transfer or disclosure of sensitive or classified information. Currently, no 
safety results exist for mixed model access controllers like that envisioned for use in the 
prototype system named Radiant Alloy. Through the mixed access control modeling of 
the security requirements12 and the security policy!3 we can provide some assurances 


11 Security model is a framework that outlines the requirements necessary to properly support and 
implement a specific security policy. [2] The model depicts the logic and rules that must be implemented to 
support the security policy, and is a mapping of the abstract goals of the policy into rules that the system 
must follow. 

12 A security requirement consists of both functional requirements where it is a statement of some 
security function or security feature that should be implemented in a system; and a non-functional 
requirement which is a statement of a constraint or expected behavior that applies to a system, and may 
refer to the emergent properties of the software that is being developed or to the development process. [13] 

13 A security policy is a statement of what is, and what is not, allowed. [3]; a statement that outlines 
how entities access each other, what operations different entities can execute, what level of protection is 
required, and what actions should be taken when the requirements are not met. [2] The security policy 
outlines goals without regard for how they will be accomplished. 
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about the safety within the system. This will be done by a construction of safety by 
definition within the context of the system architecture using use, misuse, and security 
use cases. 

A greater amount of work to verify the correctness of an MLS and a much higher 
cost is necessary due to the complexity of the system. A system is considered to operate 
in MLS mode when it permits two or more classification levels of information to be 
processed simultaneously and when all users do not have the appropriate clearance to 
access all of the information processed by the system [2]. An MLS system has added 
complexity in maintaining a separation of data and preventing unsafe or prohibited 
actions on objects within the system. The additional requirements necessary to meet a 
more stringent security policy and greater assurances required of a MLS system, affect 
the resulting security model and ultimately the implementation of that model in the final 
system. This complexity becomes apparent with the implementation of the access control 
model for the system itself. The greater complexity of the MLS access controller makes it 
harder to test and evaluate under all possible combinations of system accesses and subject 
to object pairings, and thus harder to provide assurance of its secure functionality. 
However, modeling methods have not kept pace with the rise in complexity, thus creating 
and exacerbating the separation of the system development and the underlying security of 
the system [14]. Additionally, those who are not security practitioners might view the 
added security requirements, necessary to meet a High assurance level, as an 
inconvenience that can be dealt with later. An enforcement and orchestration mechanism 
must be used to provide the integration of security policy and architecture in a SOA- 
based system. Access must be strictly controlled to enforce these security policies and 
maintain core data security. Assurance of the system’s functionality to support multiple 
levels of security hinges on four elements: the access control model, the security kernel, 
the information broker, and the information declassifier. 
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D. SIGNIFICANCE OF THE PROBLEM 


MDA and similar national security related missions require sharing of information 
of multiple levels of sensitivity across security enclaves. This has become an evolving 
challenge to maintain necessary information flows as current access control models are 
not sufficient to support desired cross-domain solution (CDS) requirements. The 
compositional model introduces emergent challenges for information rights proliferation 
(i.e., information leakage) as we model high-assurance security requirements and the 
security policy to provide for safety within the system. In this research, we specify safety 
properties of the mixed model access controller and the rules necessary to implement an 
information declassifier using a UML-based Use-Case security analysis and use RuleML 
as a means to specify information flow control policies between security domains. 
Ruleset checks are also provided to demonstrate that the safety property for information 
flows still holds with the addition of the information declassifier to the system 
architecture. By following this approach, we can re-architect an access controller to 
ensure security requirements are achieved without the specified policy violations or 
leakage of information resultant from the compositional model, thus regaining safety. 

E. RESEARCH APPROACH 

The process flow planned for conducting this research is shown in Figure 2 and 
includes the following steps; 

1. Develop a Concept of Operations as a Basis for a Security Policy-dewelop 
realistic Use Case and Misuse Cases that exercise the system requirements 
and challenge the security specifications for a mixed model access control 
system using the BLP and RBAC models. 

2. UML-based Use Case Analysis to Generate a Security Use Case and Re¬ 
architecting Development-detcrmine. the Security Use Case necessary to 
prevent, mitigate, and detect the Misuse Cases while still permitting all 
Use Cases, to maintain the safety of information flows within our system. 
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3. System Re-architecting Development-dQtQvminQ the re-architecting 
necessary to meet the Security Use Case requirements. 

a. Provide Sequence Diagrams for the Security Use case in the 
revised architecture. 

b. Develop sample data sets as a basis for the underlying system 
model. 

c. Develop sample Vessels, Queries and Alerts using XML 

d. Define Information Declassifier rules using RuleML 

4. Safety Refinement-demonstrate what constitutes safety in our 
mixed model access control system and how the architecture 
supports the concept based on the re-architecting. 

5. Rule Verification, Regression Testing, and Proof of Concept Simulation- 
use template system in a standard Maritime Domain Awareness scenario 
as a proof of concept and demonstrate technical feasibility of the 
verification of the re-architecting and the specification of the security 
policy using RuleML in a simulation of the various scenarios. 
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Figure 2. Methodology and Approach Flow 
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F. 


CONTRIBUTIONS OF THIS RESEARCH 


As described above, the composition of access controllers in a system may result 
in emergent behaviors that violate the safety property of that system. We propose a 
methodology for modeling these behaviors and re-architecting a system to detect, or 
mitigate these emergent behaviors. We also provide a sample framework that validates 
the re-architecting and uses a rule-based service to prevent the overt information flows 
and regain safety within our system. We demonstrate the adequacy of RuleML for 
modeling and reasoning about access control security policy in a cross-domain context. 
The specific contributions of this work are listed below: 

1. Developed and Used a New Methodology for Security Analysis using 
UML-based Use Case Analysis to Direct the Re-architecting of a 
System for the Preservation of Safety 

The methodology of security analysis using UML Use and Misuse Cases, allows 
for tailoring of security policies and mitigating the “highest cost” risks for information 
flow while still enabling trusted sharing. UML-based Use Case security analysis has not 
been applied in a MLS, SOA-based venue and this work utilizes that approach as an 
exemplar to provide for a greater access to information and increased sharing among 
disparate security domains. In order to support inviolate information flows to the security 
policy, and to overcome the tranquility property associated with traditional MLS systems, 
we demonstrate that Radiant Alloy needs to use an information declassifier. 

2. Developed a New Process to Allow for the Prioritization of 
Information Flows and the “Safe” Composition of Mixed Access 
Control Models through a Re-architecting of the System 

Through the process of prioritizing the information-flow needs within a system, 
we can tailor the composition of different access control models to support required 
flows. This effectively opens the information sharing infrastructure to more DOD 
organizations and provides a means for cooperation and more real-time passing of 
information between agencies. This process also helps engineers and developers combine 
“best-of’ practices in their design and implementation of an AIS. The idea of 
prioritization is based on the risk analysis and risk tolerances of the stakeholders. The 
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allowable “exceptions” to our baseline policies are considered as the only permissible 
extensions and ultimately determine what is safe for the system. The method shown in 
this research uses RuleML to enforce this policy. The need for sharing and the need to 
maintain security must be balanced to provide an operationally useful system that will 
still uphold the desired and specified safety for information flows. 

3. Created a New Process for the Development of Business Process 
Rules, using RuleML to Specify Allowed Information Flows and to 
Restrict Flows Enabling Leakage of Information from Emergent 
Behaviors and Facilitate Sharing between Information Systems 

To support the development of an information declassifier, we provide a policy- 
based framework to do so using RuleML [15]. By developing, implementing and 
enforcing business process rules through the use of RuleML, we realize a greater control 
of our information flows. The rule engine provides for a greater granularity of Need (Not) 
to Share for information within domains, facilitating the dissemination of information and 
providing increased speed of information flow to allow a greater use of “real-time” 
information, compared with traditional MAC-only policies. Current systems cannot 
support this level of information sharing and traditionally use a workaround (i.e., 
sneakernet) to meet user requirements. The extension of an open-source XML-based 
business process language to facilitate the composition of access controllers and the 
safety of the associated models provides a useful tool for software engineers in system- 
architecting efforts. 

4. Provided a Process that Allows Engineers to use Decision Tables or 
Other Methods to Develop Simple Propositions to Express Desired 
Process and Information Flows that can be Formed into Executable 
RuleML 

With the re-architecting of an information system, it is necessary to provide a 
convincing argument that the RuleML specification supports the system’s required 
information flows. By creating business process rules with RuleML to support the 
sharing of information within the system, we can show that all prior capabilities and 
intended flows are still available to the user, yet there are no unintended flows that result 
in violation of the safety property. This is an extension of the work conducted on the 
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hook-up theorem for multilevel security with respect to inference control and the 
composability of restrictiveness for security policies [41], This must be done to build a 
basis of confidence for services to be used (and reused) with respect to the Information 
Broker and its associated rule engine based Information Declassifier service. By 
regression testing, which includes running the ruleset with a sample data set, we can 
verify that our security use case is correct. This is necessary to help establish a basis for 
certification of information systems at high assurance levels. The rule-based. Information 
Declassifier service helps to automatically provide Information Broker web services with 
a means of information sharing and information filtering that is not available within 
individual access control models, and to ensure the safety of information flows in mixed 
model access control systems. This included the validation of the concept system re¬ 
architecting through the conduct of a regression testing verification and a simulation of 
RuleML content-based query injection and filtering, whose results verified the rule 
structure and usage of RuleML as a specification language. 

G. OVERVIEW OE THE DISSERTATION 

In Chapter II, we provide background information on several areas essential to 
understanding this research, as well as cover an assessment of previous work in the 
respective areas. 

Chapter III includes an introduction to the operational context that we used as a 
basis for the work. The service-oriented, cross-domain secure system is outlined as it 
pertains to this research. 

Chapter IV introduces a motivating example of why information in a cross¬ 
domain context is necessary in Maritime Domain Awareness. The Use Case scenario is 
depicted in detail, which is the basis for the re-architecting and security analysis to 
preserve safety. We describe the desired and undesired flows and the rules necessary to 
allow and prevent those flows accordingly. 

Chapter V highlights the queries system and alert messaging that are used in our 
prototype system. We describe the scenario-based query process and show examples with 
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differing Web Services (WS) languages, along with the specification of Alert Messaging 
to support the scenario. 

Chapter VI provides a summary of the re-architecting methodology and its 
subsequent rule-based execution from our prototype system. We briefly discuss the 
Security Use Case information flows that were required for the scenario and how the 
Information Declassifier supported those requirements. We also provide a prototype of 
the Information Declassifier re-architected system through a RuleML policy specification 
and its execution. 

Chapter VII highlights the contributions toward software engineering and 
information assurance as well as future directions of our research. 

H. KEY FINDINGS 

In this research, we show how the methodology for UML-based Use Case 
Analysis can be used to elicit and model undesirable information flow properties within a 
mixed access control model, SOA-based, MLS system. This provides a systematic 
approach to regaining safety and enabling trusting sharing and desired information flows, 
without violating tranquility. We also show how this analysis can be used to re-architect a 
system to detect, mitigate, or prevent undesirable information flows, and extend this re¬ 
architecting by adding rules, via RuleML, to maintain and enforce the changes in system 
architecture as a security policy specification language. By using RuleML, we show the 
feasibility of this approach that can be extended to other technologies or languages to 
specify policy and information flows. Our work provides for composing disparate access 
control model systems, allowing for an accurate, security-grounded process for policy 
management. Composing different systems with diverse access control models can result 
in information leakage, and consequently, result in the composed system violating some 
safety criteria. We have shown how this can be addressed by introducing an information 
declassifier, of which the de-classification policies can be written in RuleML. The use of 
regression testing provides verification of the content-based query injection and filtering 
for the RuleML concept ruleset. The functionality of the Information Declassifier 
mandates a response during each step of the rule firing order, requiring the use of 
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reactionary rules in RuleML. Both positive case and negative case rules were established 
and linked via forward chaining throughout the ruleset to create and enforce the policy 
model. By preventing an ambiguous or a non-response from within the ruleset, we can be 
assured that the Information Declassifier will also return a result. The MDA scenario 
provides a motivating example for cross-domain information sharing. Finally, we 
demonstrate the use of RuleML rules to maintain information flow safety within a system 
through simulation, which verified the rule structure and usage. 
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II. ASSESSMENT OE PREVIOUS WORK 


The research described in this dissertation builds on a variety of prior efforts to 
construct multilevel secure systems, enable information sharing, and realize the effective 
implementation of security policies with the support of a service-oriented architecture. 
This work also builds upon the research of McDaniel and Tardy [16] on role-based access 
control for MDA and that of Bennett [17] on defining a common intelligence picture for 
MDA. While a large amount of work has been done related to covert channels and the 
exploration of blocking those channels via different methods, the use of and mitigation of 
covert channels is not explored in this dissertation [2, 18-22]. This research covers overt 
information flows and the prevention of information leakage resultant from the 
composition of disparate systems. 

A. ACCESS CONTROL 

Access controls are used to verify that desired user accesses to system objects are 
authorized. Part of these access controls are done with an overarching policy or model, 
while the secondary piece, and arguably a highly important one as well, is the 
enforcement of the policy via an access control mechanism. The policy is used to specify 
allowable actions within a system and will be the focus of this research rather than the 
implementation or enforcement mechanism. The access control policy ensures that 
information does not flow from one set of subjects to another in the system (e.g., Top 
Secret information flowing to Unclassified), and that there is no path that exists between 
any two subjects through some combination of objects or even other subjects. Because of 
these desirable restrictions, access control must also discern between various users or 
subjects authorizations, and the objects (processes, files, data, domains, etc.) that they 
require access to. Also required is the ability to protect the subjects and objects 
themselves from improper use or modification. With many security models we find an 
underlying access matrix forming the basis for the access control policy. 

Many access control matrices exhibit the idea of ownership for objects within the 
system. In our SOA-based system, we do not rely on or implement an ownership based 
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access because of the Information Broker. The IB services user requests and acts as our 
access control mechanism. Inherent with this is the idea that the IB or the originating data 
store will have ownership of an object and not individual subjects (users). This eliminates 
the ability of subjects to grant or revoke privileges to objects, since they never have 
ownership. 


1. An Access Control Matrix 

The access control matrix (ACM) is a representation of policy and the system at a 

given state. The access control matrix model is typically regarding as the simplest 

framework for describing a protection system. An access control matrix views a system 

in terms of the set of protected entities, contained in the set of objects O; subjects 5 is a 

set of active objects, like users and processes; and the rights between subjects and objects 

drawn from a matrix A, where the set of rights R in each entry a\s,o] where s E S, o E O, 

and a[s,o] ^ R. A matrix A, captures entity relationships where rights drawn from R get 

assigned to each entry a[s,o\. The protection states of a system are then represented by 

the triple (S, O, A). Objects typically include files, memory space, and even processes. 

Subjects are typically users, processes, or domains (i.e., privileged). Each of the rights 

specified within the matrix differentiates the types of actions that can be performed on the 

respective objects. The resultant mapping of Subjects to Objects, with Rights associated is 

an access control matrix. In [12], six primitive operations are defined: 

Enter r into A [5', o] 

Delete r from A [ 5 , o] 

Create subject 5 
Create object o 
Destroy subject 5' 

Destroy object o 

These primitive operations were shown in [12] to be decidedly safe, since they are 
monotonic and that for non-monotonic systems safety is much more complex and they 
represent changes in state for the system in question. Monotonicity refers to the system in 
question only conducting one operation at a time and this is where the safety can be 
shown. It is these states of the system itself that we can relate to safety. By not allowing a 
system to reach an unauthorized state, we have effectively limited the model to safe 
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behavior. However, a safe system is not necessarily a secure system. Safety refers to the 
model of the system, while security refers to the implementation of that model in the 
actual system. This is the fundamental difference and security is what is measured during 
the C&A process. 

2. Access Control Matrix Safety 

Any system that allows for information sharing will have information flow 
leakage. This leakage is often a permissible type, where users will trust other users with 
access rights to data. The safety guarantee that we need for our systems, relates to the 
aspect of information flow wherein information directly refused to a user cannot be 
indirectly obtained by executing a set of operations. Harrison et al. [12] define 
authorization systems allowing the modification of access rights, along with the ability 
for creating and deleting subjects and objects within the system. The safety concept 
introduced, stated that access to an object within the system was impossible without the 
concurrence of the owner of that object. Since an owner in a DAC system may extend 
rights to an object that in turn may be given away without his knowledge, no protection 
system can be safe by this definition. They subsequently showed that it is generally 
undecidable whether, “given an initial access matrix, there is some sequence of 
commands in which a particular generic right is entered at some place in the matrix 
where it did not exist before” [12]. Thus, given an access matrix M and a right r (from a 
set of rights R), verifying the state of M with respect to r is undecidable. An additional 
aspect of safety of concern to a MLS system is leakage from a covert channel. A covert 
channel utilizes shared resources in a system as a path of communication to transfer 
information. This is an unintended path from the original systems design, but can be 
realized as either a storage channel or a timing channel [3]. 

3. Safety Analysis 

The safety of an access control matrix has been shown, in general, to be un¬ 
decidable. Generally, the complexity (of the security verification) is tied to the choice of 
the security model’s abstraction level, and the design principles of the security 
architecture for the implementation. 
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The overarching security policy drives the choice of the security model. In this 
case, the need to provide access right proliferation across boundaries, leads to selection of 
the Harrison-Ruzzo-Ullman (HRU) model. HRU provides access control matrices 
combined with state machines to enable security property analysis through the 
observation of state transitions. For a safety analysis of this, we want to know if it is 
possible, given an initial matrix (M), that a subject (s) can obtain a right (r) to an object 
{o)mM. This would entail a leakage problem, wherein access (via the rights) to an object 
by a subject is gained, without the concurrence of the object’s owner. 

Harrison-Ruzzo-Ullman analysis has been shown to be decidable when the model 
is restricted (e.g., mono-operational operations). But, we cannot effectively model current 
security policies with such a restricted model. Mono-operational systems are easier to 
model, but, not as useful or as expressive as required to meet the modeling needs of a 
complex policy. Based on the reduction methods proposed, if we can in fact discount the 
entire matrix and only represent sub-matrices based on domain, then we could gain a 
reduction in state space. This reduction in complexity, if reduced sufficiently, could then 
be used with fully automated safety analysis. 

Despite differing security domains, web services via SOA can be used to integrate 
these multiple domains, multiple policies, and multiple enforcement mechanisms into a 
usable framework. The RBAC model is a candidate for implementing this policy in a 
single domain, but a compositional model that extends RBAC and uniformly integrates 
between domains would be ideal. 

B. MANDATORY ACCESS CONTROL MODELS 

Mandatory access control models are the most stringent for access to objects and 
resources in a system. 

1. Bell and LaPadula Model 

The Bell-LaPadula (BLP) Model is associated with military-style classification of 
information and is used to enforce rules to provide confidentiality protection [3, 23]. The 
BLP model was developed to address the security of time-sharing mainframe systems and 
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the leakage of sensitive information, and particularly to prevent sensitive information 
from being accessed in an unauthorized manner. The BLP model is a state machine 
model that enforces the confidentiality aspect of access control, where the state machine 
is the mathematical basis to show that the model (machine) will begin and remain in a 
secure state at all times. The BLP model defines the legal transitions. The Basic Security 
Theorem, is “if a system initializes in a secure state and all allowed state transitions are 
secure, then every subsequent state will be secure” [2]. This theorem is based on two 
fundamental conditions of the model. 

The definition of the Simple Security condition, given in [23], states that a user 
can only access objects assigned an equal or lower classification level to that he or she is 
cleared for; this concept is commonly referred to as “read down.” It can be expressed as: 
S (Subject) can read O (Object) if and only if lo < Is (/ represents the security clearance) 
and S has discretionary read access to O [3]. 

The *-Property (Star Property) states that, to ensure that more sensitive 
information is not moved to less sensitive objects by malicious software, a subject cannot 
write into an object that is of a lower classification level; this rule permits “write up” but 
not “write down” [23]. It can be expressed as: S can write O if and only if /5</oand S 
has discretionary access to O [3]. 

In the BLP model, all objects in the system are assigned a sensitivity level based 

on their classification level, and all users are similarly assigned a clearance level. Each 

clearance represents a sensitivity level and all are linearly ordered (e.g., Unclassified, 

Confidential, Secret, Top Secret). This model works well for generic access to an entire 

information domain (e.g.. Secret), but to further segment usage rights we need to tailor 

the permission for objects even further within the domain, which allows us to extend the 

model by adding categories within each classification; this is generally done by using a 

lattice as shown in [3, 24] to support the “need to know” for users within a classification 

or through the use of role-based access control within each domain to generate our mixed 

model access control. Lattices can compose partial or total ordering among the elements 

of a set, where S is a finite set of elements and R is a relation. A simple linear ordering of 

security classes, shown in Figure 3, falls into a lattice structure, where S is a finite set of 
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elements (e.g., S = {Unclassified, Secret, Top Secret}), and R is a relation (e.g., R = 
(Unclassified < Secret < Top Secret}). 

{Top Secret} 

1 

{Secret} 

t 

{Unclassified} 

t 

0 


Figure 3. Linearly Ordered Lattice, from [3] 

Lattices can compose partial or total ordering among the elements of a set, where 
S is a finite set of elements (e.g., S = (x, y, z}), and R is a relation of those elements. This 
nonlinear structure allows for greater complexity in the structure and for composing 
structures with ordered sets and subsets among non-related objects [24]. Denning’s 
nonlinear lattice example is shown in Figure 4 [3]. 
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{x, y, z} 



Figure 4. Lattice Demonstrating Non-Linear Ordering, from [3] 

By adding this structure, the flow of information can be controlled and secure 
flows can be specified. 

2. Role-Based Access Control 

Role-based access control (RBAC) is another mandatory access control model 
that uses subjects, roles and permissions, as primitive entities and two mappings; subject- 
to-role mapping and role-to-permission mapping. The model maps a subject to the roles 
assigned to that subject and the role to the previously designated permission set. In this 
model, a subject obtains permission to act on an object based on permission assigned to 
the role that subject fills. Each role r is authorized to perform transactions in support of 
the role. This set of actions is defined as, trans(r). The active role that a subject is 
performing is defined as, actr(s), while the authorized roles for a subject is shown 
as, authr{s). A Boolean predicate detailing whether a given subject s can execute 
a transaction t, is shown by canexec(s, t) [3]. Given these basic definitions, we can 
construct axioms to detail the rest of the model. The rule of role assignment shows 
that if a subject can execute any transaction, then that subject has an active role; 
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(Vj' e 5)(V? e T)[canexec{s,t) actr(s) 0] [3], where S is set of all subjects and T is 
the set of transactions [3]. The rule of role authorization states that a subject must be 
authorized to assume its active role; (V^ € 5)[actr(5) c authr(s)] [3]. This rule prevents a 
subject from assuming any arbitrary role, and thus executing any transaction authorized 
to that arbitrary role. The rule of transaction authorization prevents a subject 
from executing a transaction which its current role is not authorized; 
(V^ e S)(yt e T)[canexec{s,t) g trans(actr{s))] [3]. Each of these three rules serves 
to restrict the transactions that can be performed within the RBAC system. Additional 
roles can be introduced to account for the domination of roles and for the concept of 
separation of duty for roles. The domination or containment rule can be expressed as; role 
r, contains role r„ where r,>r; and (V^ e 5)[r e authr(s) a r. > r. —> r. e authr(s)\ [3] The 

use of a separation of duty rule is critical for a military AIS in which a single user cannot 
maintain all permissions. This rule can be expressed using two roles, rj and r 2 where 
(y/s e S)[r^ Gauthr{s) ^ r 2 ^authr(s)][3]. RBAC can be effectively used for limiting 

access where the subject’s need to know must be further restricted within a security level. 
RBAC has also been shown in [25] to help provide safety guarantees for the leakage 
problem and for the separation of roles and subject authorizations to access data. RBAC 
provides for the enforcement of least privilege within a system. Least privilege is a 
design principle that guides the overall design of a system and impacts on the choice of 
security access policy used and its enforcement. Privileges are allocated to roles and then 
users are assigned to those roles. Interfaces may be constructed that are available to only 
certain subsets of the user population. An audit mechanism may provide separate 
interfaces for the audit manager, the audit operator, and the audit reviewer. The interfaces 
provide the least privilege that the user needs to complete his or her job, because each of 
the interfaces would provide different levels of functionality upon login and 
authentication. 

In addition, least privilege can be used for the internal structure of the system. 
One aspect is to construct modules so that only the elements encapsulated by the module 
are directly operated upon. Elements external to a module that may be affected by the 
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module’s operation are indirectly accessed through interaction (e.g., via a function call or 
a service request) with the module that contains those elements. Another aspect of 
internal least privilege is that the scope of a given module or component should only 
include those system elements that are necessary for its functionality, and that the 
methods through which the elements are accessed should also be minimal. Layering, 
modularity and information hiding are constructive techniques for least privilege that can 
be applied to the internal architecture of the underlying trusted foundation (e.g., 
separation kernel) to improve the system’s resistance to penetration. The kernel can also 
be configured to utilize protection mechanisms such as access control and fine-grained 
execution domains to limit the ability of a subject to perform only the tasks for which it is 
authorized. In a layered system architecture, enforcement mechanisms of the most critical 
policies depend on the high assurance layer. 

An advantage of RBAC over DAC or BLP models is the isolation of 
organizational jobs as roles and assignment of minimal permissions to complete a 
particular job function. Each role then defines a specific set of operations that a user with 
that role may perform, and a set of objects that the user may access. This provides a level 
of indirection between subjects and permissions and separates the static time role design 
from the dynamic nature of obtaining and relinquishing permissions by user and object 
mappings. This results in a relatively static system design, but one where the individuals 
filling roles may change much more frequently. 

Kuhn, in [43], shows how RBAC can be implemented on a MLS system that uses 
information flow policies corresponding to a lattice. This is done through the use of a 
trusted process acting to manage roles for the access control. RBAC on existing MLS 
demonstrates reuse of current certified and accredited systems, but does not offer the 
level of information sharing and extensibility required for modern homeland defense. 
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c. 


USE CASE ANALYSIS 


Unified Modeling Language (UML) was developed by the Object Modeling 
Group (OMG) and is an international standard used for software development [26]. It is 
known in its current version (2.0) as a graphical way to specify and construct the artifacts 
necessary for building a software system. 

1. Use Case 

Use cases are the generally accepted, standardized method used to represent and 
present system functionality. The use case describes the system’s expected usage in a 
textual format along with the diagrams. A use case describes a sequence of actions that 
provide a measurable value for the relationships among actors in a system and are best 
expressed as an expected use of a system. Use cases are organized using a UML schema. 
A use case template provides a well-defined method of outlining a system use case and 
can be used as a good basis for its development. Table 1 depicts the use case template 
used in this dissertation. 


Table 1. Use Case Template 


Item 

Contents 

Use Case Name 

Assign a name to the Use Case. 

Actors 

Name of the actor(s) who participates in the Use Case. 

Brief Description 

Summarize the Use Case scenario. 

Flow of Events 

Describe sequentially the basic behavior following this Use 
Case. 

Alternative Flow of 
Events 

For Use Cases, this occupies a partial event in the basic flow. 
Alternative flow is also meaningful, although in a lesser way. 
The alternative path is considered when the basic cases are 
interrupted by a condition in the system or a Misuse Case. 

Precondition 

Describe conditions and backgrounds that are satisfied before 
entering the Use Cases and can be ensured by the system itself. 

Post Condition 

Describe conditions that hold after the Use Case has executed 
on the system itself. 
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2 . 


Misuse Case 


A Misuse Case represents the actions that a mal-actor should be prevented from 
performing with respect to the system. The relationships between Use and Misuse Cases 
can be expressed using relations such as «extend», «include», «prevent», and 
«mitigate». Some instance of misuse can include or extend a Use Case to achieve 
undesirable system behavior, while other Misuse Cases show actions preventing the Use 
Cases. The Misuse Case template contains many of the same entities as that for Use 
Cases and includes a narrative-based textual schema, as well as a Misuse Case diagram. 
The templates are not unique, as there are many variations among recommended 
templates for Use Cases and Misuse Cases, but to be able to specify misuse requires 
examining not only a basic flow, like a Use Case, but also a secondary flow. In other 
words, we need to examine the Use Case fields and then consider which of these would 
also be relevant for a Misuse Case template. Fields such as name, actors, description, and 
flow of events, are relevant to both Use Cases and Misuse Cases. However, misuse cases 
assume exceptional events that go against standard behaviors of use cases to exploit some 
element of the system. This requires additional fields to capture the threat involved, the 
system vulnerability, and the risk of exploitation. Table 2 contains the template used in 
this dissertation for Misuse Cases. 
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Table 2. Misuse Case Template 


Item 

Contents 

Misuse Case Name 

Assign a name to the Misuse Case. 

Actors 

Name of the mal-actor who provokes the misuse case. 

Brief Description 

Summarize a Misuse Case scenario. 

Flow of Events 

Describe sequentially the basic behavior following this misuse case. 

Alternative Flow of 
Events 

For Misuse Cases, this occupies a partial event in the basic flow. 
Alternative flow is also meaningful, although in a lesser way. The 
alternative path is considered when the basic Misuse Cases are 
interrupted by a Use Case. 

Precondition 

Describe conditions and backgrounds that are satisfied by triggering 
the Misuse Cases and can be ensured by the system itself. 

Assumption 

Describe conditions that must be true, but which cannot be 
guaranteed by the system itself. 

Exploited 

Vulnerability 

Describe the vulnerability that exists in the system that is being 
exploited by the Misuse Case. 

Worst Case Threat 

Describe the outcome if the misuse succeeds. If the Misuse Case has 
alternative paths, often this condition will be or contain a disjunction 
to describe slight variations in outcome. 

Capture Guarantee 

Describe the outcome guaranteed by whatever prevention path is 
followed. If no prevention path is followed, one might alternatively 
formulate a wanted prevention guarantee, expressing what one would 
want the system to achieve with respect to the attempted misuse, but 
without stating how. 

Related Business 
Rules 

Describe what business rules are violated. 

Potential Misuse 
Profile 

Some kinds of misuse are most likely to be performed by intent 
whereas other may happen accidentally, for example. Some require 
insiders or people with enormous technical skill, while others do not. 

Stakeholders and 
Threat 

This field lists the various stakeholders and their motivations. For 
misuse cases, this slot is even more important. In this field, risks can 
simply be described textually. 

Scope 

This field represents the scope of modeling. 
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3. Security Use Case 

The combination of use and misuse necessitates a Security Use Case to mitigate, 
detect, or prevent an associated misuse. This Security Use Case represents the system’s 
method of dealing with the vulnerabilities the Misuse Case exploited within the system. 
The template used in this dissertation for Security Use Cases will model that of the Use 
Case that was shown in Table 1. 

D. SERVICE-ORIENTED ARCHITECTURE 

A service-oriented architecture (SOA) is an architecture that supports the 
discovery, binding, and execution of resources (a.k.a., services) or the composition of 
resources via a network [27, 28]. Web Services (WS) standards are available for 
implementing systems. 

In this section, we summarize [27] and introduce definitions of SOA, SOA 
characteristics, and service-orientation principles. 

In [27], Contemporary SOA is defined as follows: 


Contemporary SOA represents an open, agile, extensible, federated, 
composable architecture comprised of autonomous, QoS-capable, vendor 
diverse, interoperable, discoverable, and potentially reusable services, 
implemented as Web services. 

SOA can establish an abstraction of business logic and technology, 
resulting in loose coupling between these domains. 

SOA is an evolution of past platforms, preserving successful 
characteristics of traditional architectures, and bringing with it distinct 
principles that foster service-orientation in support of a service oriented 
enterprise. 

SOA is ideally standardized throughout an enterprise, but achieving this 
state requires a planned transition and support of a still evolving 
technology set. 
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The preceding definition on contemporary SOA is based on separation of 
concerns [27]. Services encapsulate logic for solving the decomposed individual concerns 
of existing complex problems. 

There are three basic components of the SOA architecture: services, description, 
and messaging. The service is the executable code; the (service) description contains the 
name of the service, location of the service, and the input and output exchange 
requirements; and messages are independent units of communication that the services use 
to communicate [27]. An adaptation from [27] shows these components in Figure 5. 
These components could also describe a distributed architecture; yet SOA is highlighted 
by how each of these components is designed; using service-orientation principles. 



Services 


How should 
services be 
designed? 


How should the 
relationship between 
services be defined? 


Messitge.s 


How should service 
descriptions be 
designed? 


De.saiptioii 


How should 
messages be 
designed? 


Figure 5. Basic SOA Components and Design Relation, from [27] 


Service-orientation principles are “a set of principles most associated with 
service-orientation” [27]. These principles are applied to the development of the basic 
SOA components. The eight principles are listed in Table 3. 
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Table 3. Service-Orientation Guiding Principles, from [27] 


Service-orientation 

principle 

Brief description 

Reusability 

Services are designed to support immediate and 
potential reuse 

Service contract 

Services are designed with formal contracts 
which describe the service and expose a services 
data sharing requirements 

Loose coupling 

Services are designed to relate without 
dependencies on other services 

Abstraction 

Service contracts are the only visible entity of a 
service. The actual service is of no concern to the 

user 

Service-orientation 

principle 

Brief description 

Composability 

Services can make up other services 

Autonomy 

Services are designed to be independent, self- 
governing within an explicit boundary 

Statelessness 

Services are designed so as not to manage state 
information 

Discoverability 

Services are designed to be discovered for use; 
they expose their formal contract for anyone to 
use 


One additional piece of the primitive SOA definition is what [27] calls the 
implementation platform. This is where Web Services are used to integrate the 
components and provide our service-oriented solution. 

Contemporary SOA is based on primitive SOA, but differs in that Primitive SOA 
represents what can and is being done with existing Web services technology rather than 
what is being done with current Web Services technology and what can be done in the 
future with extensions to the current WS. Table 4 lists the common characteristics of 
Contemporary SOA, as described in [27]. 
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Table 4. Common Characteristics of Contemporary SOA, after [27] 


Common Characteristics of Contemporary SOA 

Contemporary SOA is at the core of the service-oriented computing platform 

Contemporary SOA increases Quality of Services (QoS) 

Contemporary SOA is fundamentally autonomous 

Contemporary SOA is based on open standards 

Contemporary SOA supports vendor diversity 

Contemporary SOA fosters intrinsic interoperability 

Contemporary SOA promotes discovery 

Contemporary SOA promotes federation 

Contemporary SOA promotes architectural composability 

Contemporary SOA fosters inherent reusability 

Contemporary SOA emphasizes extensibility 

Contemporary SOA supports a service-oriented business modeling paradigm 

Contemporary SOA implements layers of abstraction 

Contemporary SOA promotes loose coupling throughout the enterprise 

Contemporary SOA promotes organizational agility 

Contemporary SOA is a building block 

Contemporary SOA is an evolution 

Contemporary SOA is still maturing 

Contemporary SOA is an achievable ideal 


A full description of each characteristic listed in Table 4 can be found in [27], 
This list is used to show that Contemporary SOA is neither merely Web Services and 
service-oriented principles, nor is it a commercial off-the-shelf (COTS) product that 
provides a guaranteed solution. It is a highly adaptable reference point to begin creation 
of a flexible system architecture that relies on services. The extensible Markup Language 
(XML) is the basis for much of the web services. XML Schemas are used to describe 
rules for an XML document to conform to and to provide validity through the use of an 
XML Schema Definition (XSD). The XSD is an instance defining a document by 
constraints on elements, attributes, relationships, and data. 

Web Services Description Language (WSDL), SOAP (formerly Simple Object 
Access Protocol), and Universal Description, Discovery, and Integration (UDDI) are 
commonly referred to as the first generation Web services standards [27, 28]. Each of 
these standards represents a concern for the development of a Web service. WSDL is a 
standard used to develop an XML-based document that contains, at a minimum, the 
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service name, location, and input and output requirements. This is the contract for a 
service and defines services as ports or network endpoints. The WSDL document is a 
user’s interface to an actual service and the information in a WSDL resides in a UDDI 
registry so that the service can be discovered. UDDI is a specification used to design an 
XML-based registry service for Web services. The information contained in a WSDL has 
a standard format, as outlined in the OASIS UDDI specification, and mapped to a UDDI 
data model. The UDDI is open to SOAP messaging queries, which allows for any 
registered service to be found and also describes the protocols and messaging formats 
necessary to communicate with the service in question. The communications framework 
is further described by the SOAP standard. SOAP is an XML-based language and a 
platform-independent communications protocol for exchanging messages between 
services over a network. SOAP is a stateless, one-way message exchange that is typically 
transported via HTTP/HTTPS or SMTP. A graphical representation of the core standards 
and how they relate is provided in Figure 6. 



enables 

commjnication 

between 



services 


SOAP 


Figure 6. Basic SOA with Core Web Service Standards, from [27] 
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Additionally, Web Services Business Process Execution Language (WS-BPEL) 
provides a means for specifying how to integrate elements. It is also used to import and 
export functionality by WS interfaces. This is intended to model abstract and executable 
processes where BPEL can be used as an orchestration language, so that the executable 
process and message exchange are controlled (central control of a distributed system’s 
behavior). This is different than choreography, where protocols of interaction and legal 
sequences of messages for interoperability are specified (a distributed system without 
centralized control). 

E. INFORMATION BROKER 

The Information Broker (IB) is a key service in a SOA implementation of a MLS 
system. It enforces access control policy and provides for the orchestration of security 
services. Turner et al. discuss, in [44], the creation and application of an IB in SOA-based 
system in a healthcare domain. This is a single security level, but does encompass 
multiple domains and distributed data repositories, similar to this research. Turner et al. 
use XACL as the specification language for the IB [44]. The IB can be likened to an 
Enterprise Service Bus (ESB) that provides messaging between the components or 
business logic [29]. The ESB, however, is not designed for a true SOA system to provide 
a service, but rather to interface via messaging between two dissimilar services or 
otherwise incompatible components. In contrast, the IB serves as the orchestration 
mechanism at the heart of the trusted computing base (TCB) and is replicated for each 
confidentiality level. 

F. MULTILEVEL SECURITY 

Multilevel security is used to describe systems that can operate at varying security 
levels without the need for separate hardware to provide the access to a secondary 
classification level of information. Two major categories of implementation exist for 
these systems; those utilizing a separation kernel and those without. Rushby offers that 
the role of a security kernel is to separate environments on a single processor as if they 
were running on physically separate machines [30]. Typically, it was the “one component 
that partitioned many kinds of resources (complex implementation), and either enforced a 
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single operational security property (too rigid to be useful) or several (too complicated to 
be credible)” [31]. Several foundational elements are required to include: the ability to 
prove no information flow channels exist between domains, non-bypassable, 
tamperproof, and being small enough to test and analyze completely. 

1. Separation Kernel Based 

Multiple Independent Levels of Security (MILS) is a high-assurance security 
architecture based on processing separation and controlled information flow. MILS 
allows for independent evaluation of security components and trusted composition. Much 
work has been done with MILS by VanFleet [8] as an extension of the design of secure 
systems from Rushby [30]. This is fundamentally different than the SO A based 
implementation. MILS focuses on multiple levels of security on a single system and not 
via distributed computing. MILS systems could serve as endpoints offering multiple 
sensitivity levels from a single source to augment the approach discussed in this research. 

While there is a lack—primarily due to cost—of proprietary systems that have 
been built, certified and accredited, the door has opened for the use of non-developmental 
items. Boeing is now using the WindRiver VxWorks MILS Platform 2.0 separation 
kernel for its embedded real-time systems. Additional and comparable software 
separation kernels to support MILS are offered by Green Hills (Integrity 178B) [32], and 
LynuxWorks (LynxSecure) [33]. These efforts have resulted in EAL6-I- certified systems 
with additional examples from Rockwell Collins’ AMP7, and Boeing’s Secure Network 
Sever that with additional integration and effort could result in a full implementation. 
Cisco, Microsoft, EMC and Deem partnered to create the Secure Information Sharing 
Architecture (SISA). SISA utilizes commercially available products to provide 
information sharing and separation controls at the PL3 (Medium Assurance) level [34]. 
SISA does not support SOA and is not a high assurance solution. 

2. Non-separation Kernel Based 

BAE Systems’ STOP OS is an example of a non-separation kernel based 

implementation for MLS [35]. BAE integrates the STOP OS with their Next Generation 

XTS Guard into a Secure Application Platform as the basis for specification and 
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enforcement of security policy in MLS, cross-domain environments [36-38]. This 
approach is heavily reliant on the use of the XTS Guard and the security controls 
enforced by the operating system. 

The information broker approach via SOA that is described in this research is 
based on the services and the distributed environment inherent with the model. While the 
underlying individual operating system is independent of the information broker’s 
mission, the STOP OS is designed as a general purpose OS to be run on individual 
systems to maintain data separation. The Radiant Alloy model provides for the TLS and 
IB to make the separation decisions prior to the information arriving at an individual 
system. This is an OS that could be used in conjunction with Radiant Alloy and the IB, 
but could not replace the TCB and functionality of the IB itself that we are specifying 
policy rules to implement. The functions of the operating system to control access to the 
hardware are not an implementation goal of Radiant Alloy, where any network capable 
device is inclusive of the intended platforms for use. 

McCullough, in [41], describes a security property for MLS systems called 
restrictiveness. This property refers to the ability of a user to infer sensitive information 
from the system within the scope of the security policy. Additionally, McCullough offers 
this restrictiveness as holding with a hook-up or composable property when combining 
secure systems to a single composite system. 

Goguen and Meseguer, in [42], present verification of an MLS keying on security 
policy satisfaction for a specified security model. Their approach analyzes non¬ 
interference of information flows for the security policy and the high-level specification 
to verify the security of a system. This work did not encompass inference or information 
aggregation creating security policy violations as we do in this dissertation. 

Trusted Solaris provides an implementation of RBAC and supports MLS. Trusted 
Solaris, however, is designed for the operating system processes only and not for the 
movement and dissemination of data in a distributed or SOA system. 

Osborn, Sandhu and Munawer in [39], attempted to show the inclusion of MLS 
policy (BLP) using RBAC roles. They developed models for using RBAC to encompass 
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both DAC and MAC policies via roles. The use of a lattice-based access control model 
and the generality of the RBAC model allows for the simulation of these other models. 
Despite RBAC being more expressive than BLP and allowing the limited modeling of 
MLS within a role, the implementation in RBAC relied on a single administrator role. 
This lacks the true separation of duties and responsibility necessary for a MLS system. 
This would involve a violation of the *-property, and Simple Security property. RBAC 
was defined in [40], then expanded in [41] before its acceptance by The National Institute 
of Standards and Technology (NIST) in [42]. RBAC has also been shown in [25, 43-48] 
to provide a sound platform to develop assurances of access control using administrative 
roles and varying access control mechanisms. Additionally, Kuhn provided a concept to 
provide RBAC on an existing MLS system in [43]. 

Freeman, Neely, and Heckard [14] offer a way to map security policy into a 
model based on the security requirements and the system architecture. Their Boundary 
Flow Modeling (BFM) approach helps to model the security policy with regard to the 
system architecture it will operate in, rather than trying to enforce a generic policy on an 
incompatible domain. It also allows for mathematical formalization of the policy model 
as an additional problem with a distributed system is that in general they are non- 
deterministic, since separate processors in the system execute state changes in an order 
that is not predictable relative to the others in the system. But, the security requirements 
must still be adhered to. Boundary flow modeling addresses this by defining relationships 
rather than functions, between inputs and outputs where these relationships can be 
modeled mathematically as a relation and can account for nondeterministic behavior in 
the system [14]. Their BFM method is designed to aid in the development process and 
does not provide an implementation method as addressed in this research. 

3. Other Multilevel Security Work 

Multilevel security is a common desire with information repositories. The Sea 
View security model [60] addresses the concept of multiple levels enforced by a 
reference monitor and the extension of individual data classifications in the database for 
enforcement and creates multiple database servers for every level the user dominates. 
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This approach does not allow for the capability of connecting to multiple disparate data 
stores outside of a relational database, nor does it account for the prioritization and 
emergence of additional data flows that must be accounted for within eurrent operational 
systems. 

G. GUARDS 

Guards are mechanisms designed to limit the exchange of information between 
systems [49] and utilize any number of inputs to determine the release or modifieation of 
the information in question. This is a critical element of any cross-domain effort and its 
implementation is usually the hallmark of the system architecture itself. There is much 
prior work related to differing guard implementations, yet none of these allow for the 
same level of expressiveness and granularity as provided through the integration of 
RuleML and the Information Broker described in this research. 

The Information Support Server Environment (ISSE) Guard from the Air Eorce 
Researeh Laboratory (AFRL) allows for bi-direetional email messaging, imagery, and 
Mierosoft Offiee file transfer between intereonnected domains [50]. This guard supports 
a single high-side system with up to eight low-side systems, but it does not provide a 
means for the system to ensure that labels a user associates with information provided to 
the system are eonsistent with the sensitivity levels that the user is allowed to aecess. 
This is not as scalable as the SOA-based implementation of Radiant Alloy and the guard 
eharaeteristies are defined for a limited scope of transfer [51]. The National Seeurity 
Agency (NSA) and AFRL are jointly working to integrate XML capabilities into the 
ISSE to allow for transfer between domains and provide this via web services. This is 
different than the use of RuleML with an information broker and is content based rather 
than configuration based. The ability and the need to transfer data across the domains 
using the ISSE, as well as future expansion to support new XML capabilities, is the goal. 

The Defense Messaging System (DMS) is a follow-on cross-domain messaging 
serviee created from the legacy Defense Switehed Network (DSN) AUTODIN System 
based on labels. DMS provides two categories of serviee: High Grade Serviee (HGS) 
uses modified commercial email clients and a FORTEZZA token-based Class 4 Public 
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Key Infrastructure (PKI) certificate, while Medium Grade Service (MGS) uses 
commercial email clients with a Class 3 PKI certificate [52], The DMS supports four 
DMS security domains: Unclassified (U), Secret (S), Top Secret-Collateral (TS) and Top 
Secret/Sensitive Compartmented Information (SCI); according to the transport network. 
DMS utilizes a High Assurance Guard (HAG) for cross-domain exchange of message 
traffic, which is different than the use of an information broker as the central control 
element between data repositories. The idea of disparate classifications using a message 
system is limited in the ability of the guard to check the content and parse the messages. 

The Navy Research Laboratory (NRL) modified its original Pump to a Network 
Pump to create a high assurance guard that supports cross-domain messaging [53]. This 
allows transfer from low to high and prevents the downward flow, but also provides an 
acknowledgement indication of the transfer back to the low-side. This approach also 
relies on modifying the timings of the response messaging in order to mitigate the use of 
transfer responses as a covert channel. This approach has a few drawbacks compared 
with the use of an Information Broker and specification of policy using RuleML. 
Although offering limited support of information sharing among disparate users, the 
types of transfer are limited while the use of RuleML specifying a security policy allows 
for greater expressivity and can also be constructed to eliminate the inference ability of a 
lower classification user. This also allows for multi-level classification of information 
and thus, a different view related to similar objects between users (e.g., a ship’s detailed 
track history). The NRL Pump also is intended as a part of a larger collection of networks 
rather than as an information destination connected via a service-oriented architecture 
and rapidly scalable via a replication of IB service and is only a one-way guard as 
opposed to bi-directional. 

The Monterey Security Architecture (MYSEA) is a related concept to allow for 
distributed information sharing for MLS [54]. However, the MYSEA is an 
implementation of the Trusted Computing Base (TCB), and would serve as a viable 
alternative to Radiant Alloy as used in this research. The MYSEA does not implement a 
defined ruleset supporting policy, but rather the environment in which to create the 
enforcement and authorization mechanisms for the multilevel security policy. 


43 



BAE Systems uses the Next Generation XTS Guard as an integral piece of their 
Secure Application Platform, along with the STOP OS described previously [36-38]. The 
XTS Guard is designed for use as a gateway for desktop, server, or network 
environments. It is designed to separate data from varying security levels based on label 
and sensitivity, yet it does not allow for the openly configurable rulesets and must rely on 
proprietary hardware and software elements to provide its services. 

H. FIREWALL AND IPS LANGUAGES 

Current enterprise-level firewalls and Intrusion Protection Systems (IPS) have 
reached a level of sophistication that was not available in prior generations of devices. 
The prior reliance on port number, protocol, and IP address filtering have been 
superseded by a more dynamic ability to restrict or block traffic based on triggers and 
performance thresholds established for the device. While the functionality and concept of 
creating and running rules to support filtering and blocking of network traffic by a 
firewall and intrusion protection system (IPS) are similar, the firewall and IPS rules are 
much different than the use of RuleML in this research. Typical configuration of these 
network appliances is via a graphical user interface (GUI) and is proprietary to each 
respective vendor. However, these are all similar in the underlying rule generation, which 
is very simple logic. This allows for the devices to operate at very high data rates to 
perform the specific function of filtering content in the network, but does not permit 
complex logic such as a filtering of a suspicious domain based on recent network traffic 
patterns. These firewall rules are executed in a simple beginning to end list, where the 
first rule is evaluated and if it is not triggered the execution continues to the next rule in 
sequence [55]. As soon as a rule is triggered, the remaining rules are ignored and the 
initial decision is upheld for that particular rule. This prevents the ability to ensure rule 
consistency throughout the rule list and is one of the primary concerns, from both 
network appliance vendors and enterprise clients, as rulesets for these devices become 
ever larger to account for growing enterprise needs and emerging threats. 

Multiple vendors offer network appliance solutions, such as firewalls (FW), 
intrusion protection systems (IPS), and intrusion detection systems (IDS). Each of these 
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has a variation with its own corporate branding and a different user interface, yet the 
underlying structure and execution models are similar. Cisco Systems Inc. offers the ASA 
5500 Adaptive Security Appliance [56] line of firewalls as the top-tier of their efforts. 
Check Point Software Technologies Ltd. offers the 61000 Security System [57]. McAfee 
Firewall Enterprise [58] is the top offering of McAfee and is branded as a next-generation 
device. While each of these vendors touts advanced security and adaptive measures for 
filtering and content control, the underlying operation is still reliant on a simple logic that 
lacks complexity and expressiveness. Overcoming these weaknesses, RuleML in our 
example allows for the use of chaining rules and can be checked for consistency with the 
ruleset. The ability to add a complex rule is also evident in RuleML. However, while this 
functions well for a specific enterprise device, it is not expressive enough and only covers 
a single domain when compared to the use of RuleML and an Information Broker as we 
describe 

In line with the network appliance is the functionality offered by the IPS, and how 
it processes network flow. One of the most widely used of these, offering both an open 
source rule engine and rule language, is Snort. Snort allows you to extend its predefined 
syntax and rules to meet the needs of the network. This is a common application within a 
corporate enterprise network and is used on many different hardware appliances to 
support intrusion detection and prevention. A Snort rule can be broken down into two 
basic parts, the rule header and options for the rule. The rule header contains the action to 
perform, the protocol that the rule applies to, and the source and destination addresses 
and ports. The rule options allow you to create a descriptive message to associate with the 
rule, as well as check a variety of other packet attributes by making use of Snort’s 
extensive library of plug-ins. The generic Snort rule is: action protocol src_ip src_port 
direction dst_ip dst_j)ort (options) [59]. This is again simple logic, not allowing for rule 
chaining and lacking in expression for more complex filtering. When a packet comes in, 
its source and destination IP addresses and ports are compared to the rules in the ruleset. 
If any of them is applicable to the packet, then the options are compared to the packet. If 
all of these comparisons return a match, then the specified action is taken. All other rules 
in the set are excluded from consideration after a single rule is triggered. As we can see. 
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the underlying basis is simple and designed for speed of execution for high-flow network 
entry points where throughput is paramount. Yet, these rules and the language used to 
support them are not sufficient to meet the needs of our cross-domain information broker. 

I. XACML 

extensible Access Control Markup Language (XACML) is an OASIS standard. 
XACML is the access controller of the Web Services languages and the current reference 
implementation has a single policy decision point (PDF) and a policy enforcement point 
(PEP). 
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The current XACML specification has three main entities as shown in Figure 7. 
The main components are: 

1. Policy Administration Point (PAP): Entity that creates policies or policy 
sets. 

2. Policy Decision Point (PDP): Entity that evaluates applicable policy and 
renders an authorization decision. The answer given by the PDP is one of 
(1) permit, (2) deny, (3) insufficient information to decide or (4) error, 
occurred in the execution. 

3. Policy Enforcement Point (PEP): Entity that performs access control by 
enforcing authorization decisions. 

Figure 7 also shows the dataflow of the XACML reference implementation. First, 
the PAP creates a policy. At request time, an access request arrives at the PEP (flow 2), 
and is sent to the context handler (flow 3). The context handler determines resources to 
be accessed and attributes of the requester, resource and the environment, collects all 
required attributes and forwards them to the PDP (flows 4 through 8). The PDP then 
acquires the policy from PAP (flow 1), evaluates the relevant policy and relays the 
decision (flows 9, 10) to the PEP through the context handler, which then enforces the 
authorization decision [60]. 

The policy syntax (XML) includes language constructs to identify the resource, 
the action (to be performed on the resource), the subject, and constraints on the access. In 
XACML parlance, this collection of entities is called a target. The request syntax (XML) 
identifies the resource, the action, the subject. The decision engine (PDP) matches the 
incoming request to available policies to discover all applicable policies. If more than one 
policy is applicable, then the PDP uses a policy-combination algorithm [61] to determine 
the evaluation result. In essence, the combination algorithm states how to combine the 
result of each applicable policy. For example, it can state that the final result is the 
conjunction/disjunction of the individual results, or the first-applicable policy evaluation 
result is the final result [60]. 
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J. RULEML 

Rule Markup Language (RuleML) specifies Prolog-like rules that use an XML- 
like syntax, and consequently are valuable with SOA. RuleML was initially developed by 
the Rule Markup Initiative to express rules in XML for various tasks. The semantic 
foundation of RuleML is based on datalog, which combines SQL and Prolog, and can be 
considered as a subset of logic programming [62]. RuleML serves the Resource 
Description Framework (RDF) as a canonical Web language. Wh i le RDF is the basis for 
the larger data interchange within the web, RuleML covers the entire rule spectrum, from 
derivation rules to transformation rules to reaction rules. RuleML can be used to specify 
queries and inferences in Web ontologies, mappings between Web ontologies, and 
dynamic Web behaviors of workflows, services, and agents [10]. 

The RuleML package provides a namespace for XML, facilitating reuse. Top- 
down or bottom-up rules can be used, specifying deductive logic, rewriting, and 
inference. Rules can be stated in natural language, some formal notation (e.g., Backus- 
Naur form), or in a combination of both. The combination of natural language and formal 
notation offers the most nearly universal appeal to permit Web-based rule storage, 
interchange, retrieval, and application. 

The RuleML namespace has a hierarchy of rules that consists of varying 
categories: reaction, transformation, derivation, facts, queries, and integrity constraints. 
The hierarchy is shown in Figure 8, where two main categories of reaction rules and 
transformation rules form the basis for all other categories of rules. 
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Figure 8. RuleML Hierarchy, from [10] 

While general rules, as the all-encompassing rule category, could implement all 
other categories of rules, special-purpose syntaxes for each of the subcategories were 
created to allow for ease of refinement and application. The following show basic markup 
syntaxes for each of the various categories: 

• Reaction rules: <react> <_event> trigger </_event> <_body> <and> 
preml ... premN </and> </_body> <_head> action </_head> </react> 
reducible to <rule> <_event> trigger </_event> <_body> <and> preml 

... premN </and> </_body> <_head> action </_head> <_foot> empty 
</_foot> </rule> 

• Transformation rules: <trans> <_head> cone </_head> <_body> <and> 
preml ... premN </and> </_body> <_foot> value </_foot> </trans> 
reducible to <rule> <_event> active </_event> <_body> <and> preml ... 

premN </and> </_body> <_head> cone </_head> <_foot> value 
</_foot> </rule> 

• Derivation rules: <imp> <_head> cone </_head> <_body> <and> preml ... 
premN </and> </_body> </imp> reducible to <trans> <_head> cone 

</_head> <_body> <and> preml ... premN </and> </_body> <_foot> 
true </_foot> </trans> 


49 




• Facts: <fact> <_head> cone </_head> </fact> reducible to <imp> 
<_head> cone </_head> <_body> <and> </and> </_body> </imp> 

• Queries: <query> <_body> <and> preml ... premN </and> </_body> 
</query> reducible to <imp> <_body> <and> preml ... premN </and> 
</_body> <_head> bindings( varl, ..., varK ) </_head> </imp> 

• Integrity constraints: <ic> <_body> <and> preml ... premN </and> 
</_body> </ic> reducible to <query kind="closed"> <_body> <and> 
preml ... premN </a.nd> </_body> </query> 

Reaction rules incorporate various production, action, reaction, complex event 
notification, event messaging and temporal or action logic rules. These rules can be 
reduced to general rules that return no value and these rules can only be applied in the 
forward direction in a natural fashion, checking (observing) for events (conditions) and 
performing an action if and when all events have been recognized (fulfilled). Reaction 
rules allow for event notification and messaging between services, as well as temporal 
and state-based logic rules. These types of rules still provide structure to accommodate a 
wide range of business cases in their expressiveness. Production rules are action rules 
where a condition is met, the IF, and an action is taken, the DO. Action rules consist of 
triggers, the ON, resulting in the action, the DO. Overall, reaction rules are most often 
exemplified as logic rules like those used in a firewall configuration. The forward 
chaining of rules is popular with expert systems and production rule systems. Forward 
chaining uses data points against the ruleset to infer additional information, as the data is 
compared to the existing rules. By checking the antecedent or IF clause of a rule, the 
consequent or THEN can be inferred. These conclusions then add further data points to 
use against the ruleset until an endstate or goal clause is reached. Overall, forward 
chaining ends with a result based on the original data and additional data points arriving 
from a changing situation can quickly be addressed by an existing ruleset to gain 
additional inferences and realize a new endstate. 

In contrast, the backward direction is normally preferred for transformation rules. 
The category of rules can be reduced to general rules whose event trigger is always 
activated. Backward chaining begins with a result and seeks to find rules that will support 
the endstate. Each of the consequents, or IE statements, that are required to reach the goal 
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endstate are added to the inference chain as items to resolve and additional goals to 
match. This method is used in automated theorem provers and expert systems and uses 
the goals to determine which rules become active, as opposed to checking the rules with 
the data given and inferred as in the forward chaining process. 

Derivation rules can be reduced to transformation rules that on success return 
true. They can be applied in the forward direction or in the backward direction equally. 
The backward direction reduces the proof of a goal (conclusion) to proofs of all its sub¬ 
goals (premises). Since in different situations different application directions of 
derivation rules may be optimal (forward, backward, or mixed), RuleML does not 
prescribe or restrict any one of these. Facts can be reduced to derivation rules that have 
an empty conjunction of premises {true), and facts or unit clauses have no applied 
direction. Derivation rules are based on reasoning and typically expressed as an IF-THEN 
relationship. 

RuleML also supports the use of queries within the basic code structure. These 
queries can be reduced (transformed) into derivation rules. Each query transformed to a 
derivation rule will have a false conclusion. Queries also are applied as top-down goals 
and can be proven backwards; but they can also be proved forward via goal-directed 
bottom-up processing. Integrity constraints can be reduced to queries that produce no 
variable bindings (closed), and are usually forward-oriented (i.e., triggered by update 
events). However, integrity constraints can also be backward-oriented, to show 
(in)consistency by fulfilling certain conditions (without recognizing an event). 

In this research, reaction rules will be used to provide a forward chaining path to 
demonstrate the viability of specifying a security policy for the information broker. The 
overall ruleset is simplified to account for a limited number of cases as presented in this 
work. The use of more sophisticated rulesets and using other types of RuleML rules, like 
derivation and transformational rules, is not explored but is possible with this 
specification. 
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III. OPERATIONAL CONTEXT 


The operational context of our study is the Navy Tactical Exploitation of National 
Capabilities (TENCAP) Program’s prototype information brokering system named 
Radiant Alloy. Radiant Alloy is a service-oriented, multilevel secure, enterprise 
information system designed to provide confidentiality for users of varying security 
levels, and data stores of various security levels over heterogeneous domains. Radiant 
Alloy provides a trusted means for sharing both unclassified and sensitive data among 
diverse user levels and domains, while maintaining anonymity of the data source, as 
depicted in Figure 9. 
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Two separate security levels (A and B) are shown, along with the system’s 
intention to prevent interaction between the levels during its use, indicated by the “No 
Transfer” bar. The information broker (IB) resides behind firewalls and network edge 
protection, yet is accessible using web services (WS) for a mixed MLS-RBAC model 
where MLS will divide varying levels of systems such as JWICS (Top Secret), SIPRnet 
(Secret) and NIPRnet (Unclassified). RBAC will be used within each domain to enforce 
further control of access (i.e., finer granularity) based on the roles of individual users. 
The IB is also expected to prevent inadvertent disclosure of information between security 
domains and facilitate authorized sharing (i.e., answer valid queries) among classification 
domains. This is a critical capability of interest to both the Homeland Defense and 
Security communities. The IB must also allow authorized transfer and downgrading of 
data for users of differing domains. The Trusted Data Connector, shown in Figure 9, is 
the plug-in point for the data repositories and serves as the trusted service within the 
system. Our Use Cases and Misuse Cases capture example scenarios in which the 
information is needed to be shared between different domains and the inferences that 
need to be prevented while sharing this information. 

Data accesses are controlled by the IB core and the trusted data connector for each 
security level, where the IB is replicated. In a MLS system, the IB must be replicated to 
allow for separation of the domains. However, this adds complexity to the system since 
the IB must now maintain consistency between implementations, in addition to isolating 
users from the data sources. The IB must also support global and local instantiations for 
each of its domains. The localized version will allow for finer and more restrictive 
control at a local level, but must be integrated and verified against the global IB for 
access requests. While the local IB policy must be equal to or more restrictive than the 
global IB for accesses, it must also verify requests with the global version to enforce the 
more restrictive control; that is, the local version cannot give more access, it can only 
lessen the level of access. This would also account for changes made at the global IB that 
may not yet be reflected in a localized instantiation of the IB for that security domain. 
Each IB will have a separate Policy Decision Point (PDP) to evaluate access requests. 
This local decision must be sent to the master or global PDP to combine the access 
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decision into a finalized context. The IB must also allow for a user to have write access to 
a lower level data store (which is explicitly forbidden in the BLP model), as well as 
preventing leakage from different domains. The information broker must enforce a mixed 
model access controller to provide the separation of users and data necessary to protect 
and enforce the confidentiality, integrity, and availability in a MLS system, as opposed to 
a monolithic security kernel that brokers all accesses and controls all resources. The IB 
also serves as a request broker for use with many different back-end data sources. The IB 
must ensure that all requests are executed within the databases at the security level at 
which requests are made and limits the results based on the clearance of the requesting 
user or the classification level of the network connection whichever is more restrictive. 
The user is authenticated to the IB and not to the data source directly, thus never 
obtaining permissions for the true data-store object. This provides anonymity and 
integrity of the source, as well as prevents users from undesired (from a security 
viewpoint) file operations [63]. 

Trusted sharing among classification domains is a critical capability of interest to 
both the Homeland Defense and Homeland Security communities. The IB must also 
allow authorized transference and downgrading of data for users of differing domains. 
Radiant Alloy will provide a means of secure^^ and trustedi^ information sharing that is 
currently non-existent at the enterprise level across communities of interest. The ideas of 
a secure system and a trusted system lead us to the certification and accreditation process, 
where the trusted system is one that meets “well defined requirements under an 
evaluation by a credible body of experts who are certified to assign trust ratings to 
evaluated products and systems” [3]. This process allows us to assign a level of trust to 
the architecture, implementation, life cycle and management, and disposal of the system 
to meet the information assurance requirements necessary for the intended application. 
As the level of trust increases, so do the number of requirements and the stringency of 

14 Secure sharing refers to the ability of the system to protect the confidentiality of information from 
inappropriate access across the varying security domains [3]. 

15 Trusted sharing refers to the level of confidence or belief that users have in the ability of the system 
to protect their information and resources across those same domains to be safe from compromise [3]. 
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those requirements. Ultimately, we cannot guarantee a system to be secure but we can 
assert a level of trust to the protections and security mechanisms'^ the system affords. 
This includes the implemented functionality, as well as the assurance that the 
functionality is correct. No SOA system has been accredited at a High Assurance level. 
One of the reasons for the overall lack of certified and accredited systems is that the 
architectural implementation and the security policies that we are trying to enforce within 
that system are difficult to implement, while maintaining the viability of the original 
system intent. Security properties, and the formal models associated with them, can be 
used to gain improvements in effectiveness, efficiency and correctness of a system’s 
security properties. But, bridging the gap between security requirements and the security 
mechanism s used in an implementation is very complex and expensive. When designing 
a system architecture to support a foundational requirement of security, we often lose 
capabilities in other areas, such as usability or performance. This has become a stumbling 
block in creating and fielding systems, because if they meet the requirements for High 
Assurance they often sacrifice in other areas and might not meet the user needs. Navy 
(TENCAP) is attempting to build a service-oriented architecture that supports MLS. 
Figure 10 depicts the proposed system architecture for Radiant Alloy at the high- 
assurance level. This architecture supports multiple user bases, multiple data stores, and 
industry-standard protocols for implementation, through the use of a mixed model access 
control (MMAC) policy. In the MDA context. Radiant Alloy offers the ability of an 
Unclassified user to obtain data from a data store, while a Secret user is obtaining a 
similar data feed (but with more detail commensurate with the classification) from the 
same data source. It becomes a significant problem, however, if a lower level user can 
observe any service delays when the higher level user is being served by the system. This 
then becomes a covert channel, which is contrary to one of the primary objectives of an 
MLS system, that being preventing creation of covert channels. This becomes not only a 
challenge to designing and implementing a system, but also to the certification process to 
ensure that it is free of covert channels or that the channels have very limited bandwidth 


16 Security Mechanism is a method, tool, or procedure for enforcing a security policy [3]. 
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where the risk of exploit can be accepted by the system owner. In a shared resource 
system, it becomes impossible to remove all the covert channels. This ability to share 
data, without attribution to the source, and to multiple users among differing domains 
concurrently, would serve as a true combat multiplier for our military. 



Figure 10. Radiant Alloy Architecture for High-Assurance, from [7] 


Collection and dissemination of information are handled well by single-level 
systems, within homogenous domains. When we move out of that context, our 
information sharing abilities become more challenging and the sharing of information can 
rapidly degrade if our systems are not designed to accommodate this sharing. This is 
attributable to both our military’s mindset toward not giving away anything the enemy 
might use against us, as well as the technological difficulty of creating an information 
system that we can trust,i^ to reliably and securely share data without compromise. 
Architectures, particularly distributed and service-oriented architectures, pose a challenge 

17 Trust is a measure of tmstworthiness, relying on the evidence provided; where an entity is 
trustworthy if there is sufficient credible evidence leading one to believe that the system will meet a set of 
given requirements [3]. 
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to meeting security requirements for a multilevel system. However, security SOA 
systems are experiencing greater integration with current MLS systems. This integration 
results in a greater need for solid, technical-based security assurances for the architecture. 
This is based on the additional security requirements that a MLS system is designed to 
meet, which provide some level of trust and assurance to the user. It is with this intent 
that we developed our Maritime Domain Awareness scenario. 
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IV. USAGE SCENARIOS 


A. MARITIME DOMAIN AWARENESS HIGH LEVEL ALERT SCENARIO 

Our application scenario comes from Maritime Domain Awareness (MDA)^^, 
which would encompass the proposed Radiant Alloy system. The SysML^^ view of this 
domain example is shown in Figure 11. 


bdd [Package] Structure ![MDADomain]^ 



Figure 11. MDA Domain SysML Diagram 


In the scenario, ships depart Southeast Asia and sail toward ports on the West 
Coast of the United States. Under normal circumstances the harbormasters at these ports 
share information about the ships expected departure and arrival times and contents of the 
cargo. In addition, other external resources develop information (which originates in 

18 Maritime Domain Awareness is the effective understanding of anything associated with the 
maritime domain that could impact the security, safety, economy, or environment of the United States. 

19 The Systems Modeling Language (SysML) is general purpose visual modeling language for 
systems engineering applications. SysML supports the specification, analysis, design, verification and 
validation of a broad range of systems and systems-of-systems. 
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different systems with higher classification levels that emits system-high alerts) that may 
mandate extensive searches of ships that take this normal course, the information ought to 
be shared in a way that hides the sources (and methods of collection) of the information, 
and make it appear to be information received through pre-arranged communication 
channels. For this research, assume that USS Antietam (CG-54), which is performing an 
interdiction mission in international waters in the Pacific Ocean, can generate high-level 
alerts about other ships. The Use Case (shown in Figure 12) can be extended to the 
application scenario as follows: 

• The ship GlobalstarV becomes identified as a Vessel of Interest (VOI). 

• The USS Antietam encounters GlobalstarV in international waters and 
stops the ship as part of its mission or merely observes the ship via other 
means. 

• The Electronic Warfare Officer (EWO) onboard the USS Antietam, 
utilizing available sources of information, obtains data about the VOI and 
aggregates data from these sources. 

• The EWO updates the track for the GlobalstarV in accordance with his 
duties and responsibilities. 

• The EWO sends an Alert Notification to the destination port’s 
Harbormaster. 

• The notification advises the destination port (San Diego) to watch for the 
VOI (i.e., GlobalstarV) and alert upon arrival. 



Eigure 12. High Level Alert Use Case Diagram 
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Within the system boundaries an Information Broker is the key respondent to 
access requests, information queries, and data access. The system architecture for the 
MDA scenario and the Use Case is shown in Figure 13 and Figure 14. 



Figure 13. Graphical Representation of Use Case System Architecture 
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While considering the system architecture and the overall scenario for the Use 
Case, we must illustrate the actions for all actors with a UML Sequence Diagram, as 
shown in Figure 15. 



Figure 15. Sequence Diagram for High Level Alert MDA Scenario 


The sequence diagram also depicts the mal-actor as an alternative flow of events, 
since he is not overtly trying to misuse the system. His actions are merely in the 
performance of his duties and show the sequencing that results from the system 
interaction. 
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1. High Level Alert Use Case 

During the performance of duty on the USS Antietam, the EWO has (Top Secret 
level) data via a variety of intelligence means (e.g., electronic, signals, and human 
[ELINT, SIGINT, HUMINT]) to confirm ship, track and other details which from the 
composition of the data sources can give an aggregate picture of the VOL These sources 
can also be used to compose other attributes, such as track history, port history, or even 
Measurement and Signature Intelligence (MASINT) data signatures that may be lacking 
from the original information about the ship. This combined data represented in a new 
and more detailed view, then categorizes at a higher classification level than originally 
intended (i.e.. Top Secret instead of Unclassified). Table 5 shows the detailed Use Case 
for the Electronic Warfare Officer serving onboard the USS Antietam. 


Tables. High Level Alert EWO Use Case 


Item 

Contents 

Use Case Name 

Ul-High Level Alert 

Actors 

EWO (Top Secret) 

Brief description 

EWO is aboard a U.S. Navy Cruiser class ship 
performing an interdiction mission. EWO is responsible 
for information and tracking of all ships in a theater of 
operation using ELINT, SIGINT, HUMINT, IR, and 
imagery. For vessels of interest, the EWO can query and 
update information in the system regarding those ships 
via his array of data collection sources. 

For particular vessels of interest, the EWO can put a 
watch on those ships at arriving ports and monitor via 
intelligence methods available to him. 

Flow of events 

1. EWO (Top Secret) logs in to the system (IB) 

2. IB authenticates user to PDF 

3. IB creates a session for the user 

4. EWO requests data via a query to the IB 

5. IB queries data stores 

6. IB provides data (TOP SECRET and below) to 
the EWO 

7. EWO synthesizes data and updates track and 
vessel information. 
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Item 

Contents 


8. EWO requests IB to write data into the system. 

9. IB verifies EWO to PDP 

10. IB performs write operation to data store 

Alternative flow of events 

1. EWO (TOP SECRET) logs in to the system (IB) 

2. IB authenticates user to PDP 

3. IB creates a session for the user 

4. EWO requests data via a query to the IB 

5. IB queries data stores 

6. IB provides data (TOP SECRET and below) to 
the EWO 

7. EWO exits the system 

Precondition 

User is an authorized user of the system and has a valid 
role (EWO) established in the system. 

TOP SECRET level access to the system is available via 
a terminal. 

Post-condition 

User is authorized user of the system and has a valid role 
(EWO) established in the system. 


The Unclassified level hosts another actor for the Use Case. This actor is the 
Harbormaster (role) for the port of San Diego where the Alert Notification will be 
directed. The Harbormaster is responsible for all inbound and outbound traffic for the 
entire port. He must manage berthing space and overall flow in the performance of his 
role. The Harbormaster is also obligated to comply with alert messages and adhere to his 
primary responsibilities. Based on an Alert Notification, the Harbormaster is instructed to 
watch for GlobalstarV arriving at an approximate date-time group (DTG)^° from the Port 
of Shanghai, China and report upon arrival. Table 6 depicts the detailed Use Case actions 
for the Harbormaster. 


This is a messaging time format used by the U.S. military. 
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Table 6. High Level Alert Harbormaster Use Case 


Item 

Contents 

Use Case Name 

Ul-High Level Alert 

Actors 

Harbormaster (Unclassified) 

Brief description 

Harbormaster is responsible for inspection and 
management of all ships entering and leaving the port. He 
must know: Existence of the vessel, scheduled arrival, 
reported size, port of origination, other? 

Using the harbormaster role; allows for queries to the 
system for information pertaining to origination port, 
destination port, expected arrival time (window), size/class 
of vessel, and name. 

Flow of events 

1. User (UC) logs in to the system (IB) 

2. IB authenticates user to PDP 

3. IB creates a session for the user 

4. User requests data via a query to the IB 

5. IB finds the relevant data store 

a. Managed by this IB 

b. Managed by another IB 

6. IB queries the data store(s) 

7. IB provides data that meets the query criteria and 
that is authorized per the Role-Permission mapping 
and security level for the Harbormaster 

Alternative flow of events 

1. User (UC) logs in to the system (IB) 

2. IB authenticates user to PDP 

3. IB creates a session for the user 

4. User requests data via a query to the IB 

5. IB finds the relevant data store 

6. Managed by this IB 

7. Managed by another IB 

8. IB queries the data store(s) 

9. Harbormaster is not authorized any data and IB 
provides a negative data found response 

Precondition 

User is an authorized user of the system and has a valid role 
(Harbormaster) established in the system. 

Access is available via a terminal to the information system 

Post-condition 

User is authorized user of the system and has a valid role 
(Harbormaster) established in the system. 

Data is used to perform the duties of Harbormaster 
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These two actors in these two Use Cases (i.e., EWO and Harbormaster) that are 
operating at different security levels combine their roles to perform a standard maritime 
mission. These actions, however, and the actors’ associated duties and responsibilities, 
also establish a basis for our Misuse Case. 

2. High Level Alert Misuse Case 

The Misuse case is designed to reveal a security problem, where the system is not 
performing its intended use. The mal-actor in this Misuse Case is actually one of our 
actors from the use case, the Harbormaster. After receiving an Alert Notification 
concerning the vessel of interest, the Port of San Diego Harbormaster queries his system 
for all ships destined to his port and originating from the Port of Shanghai. But, the 
GlobalstarV does not show on this list-from this the Harbormaster can infer that someone 
knew about this ship and its questionable nature (since he was told to watch for its 
arrival) but he was not authorized this information from his access to the system. Now, 
there is an unintended flow (existence) of Top Secret information to the lower 
(Unclassified) level, and the creation of a covert channel, violating the *-property (i.e., no 
write down) of the BLP model. The Misuse Case system architecture overview is shown 
in Figure 16 and Figure 17, while the detailed Misuse Case is shown in Table 7. 



Figure 16. Graphical Representation of Misuse Case System Architecture 
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Figure 17. Misuse Case System Architecture 
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Table 7. High Level Alert Misuse Case 


Item 

Contents 

Misuse Case Name 

MU 1-High Level Alert (Transition to Lower Level) 

Actors 

Harbormaster (Unclassified), Electronic Warfare Officer (TOP 
SECRET) 

Brief Description 

The Harbormaster is informed of a Watch Alert for a particular ship 
(GlobalstarV), inbound from Shanghai, China to arrive at an 
approximate DTG. 

Harbormaster logs in to the system and requests data from the 
system (using one of his authorized queries) for all ships arriving to 
his port (San Diego) from the Port of Shanghai, China. 

The system (IB) provides data to the Harbormaster based upon his 
role and clearance level, but that ship (GlobalstarV) is not in the 
data set provided by the system. 

Around the approximated DTG the GlobalstarV ship arrives in his 
port. 

The Harbormaster can infer that he was not privileged to this 
information and that the system has other types of collection / 
reporting assets that created and verified this ship’s track. 

Flow of Events 

1. User (UC) logs in to the system (IB) 

2. IB authenticates user to PDP 

3. IB creates a session for the user 

4. User requests data via a query to the IB 

5. IB finds the relevant data store 

a. Managed by this IB 

b. Managed by another IB 

6. IB queries the data store(s) 

7. IB provides data that meets the query criteria and that is 
authorized per the Role-Permission mapping and security 
level for the Harbormaster 

Alternative Flow of 
Events 

1. User (UC) logs in to the system (IB) 

2. IB authenticates user to PDP 

3. IB creates a session for the user 

4. User requests data via a query to the IB 

5. IB finds the relevant data store 

a. Managed by this IB 

b. Managed by another IB 

6. IB queries the data store(s) 

7. Harbormaster is not authorized any data and IB provides a 
negative data found response 
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Item 

Contents 

Precondition 

User is cleared (Unclassified) and has a role (Harbormaster) in the 
system 

Assumption 

A ship exists that is of a particular concern and has a track related 
update performed by a higher clearance level user. 

Exploited 

Vulnerability 

An out of band signaling channel exists and is utilized in the 
performance of duties. 

Worst Case Threat 

The Harbormaster can make an inference from the out of band 
signaling about the system and divulge privileged information. 
Could also divulge the identity of the sender (for the Alert) 

Capture Guarantee 

No out of band (outside of system) communication is allowed (via 
phone, email, etc.). All communications must go through the 
system (and the IB). 

Related Business 
Rules 

Scope of duty for the EWO to report the threat as an Alert 
notification to the harbor and within the scope of duty for the 
Harbormaster to acknowledge and respond/watch for the vessel 
indicated in the alert notification. 

Potential Misuse 
Profile 

This misuse could happen accidentally and does not require ability 
or skill beyond that of a normal Harbormaster user who can query 
the system and possesses an average intellect to infer that someone 
knew about the ship’s arrival, but it was not in the system. 
Intentionally, the misuse can be exploited using other authorized 
queries (per the Harbormaster role) against other facts (i.e., DTG of 
expected arrival, size of ship, destination port, or ship name). 

Stakeholders and 
Threat 

System Designers / Developers-system implementation is 
compromised because of the out of band signaling used 

Certifiers & Accreditors-system does not provide assurance and 
meet requirements to pass certification 

Trainers for the users (Actors) in the system-users do not perform 
their duties as instructed and open the out of band signaling channel 
to compromise the system 

Scope 

Maritime scenario 


This scenario is certainly not limited to this single misuse. It is merely being 
offered as an example scenario to drive the Use Case analysis and to provide a basis for 
the system’s response via the Security Use Case. 
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3. High Level Alert Security Use Case 

Our problem that originates from this Misuse Case is the uncontrolled 
observability of differing security domains. This violates the safety of both access control 
models within the system and the specified information-flow control policies. The 
combination of use and misuse necessitates a Security Use Case to mitigate, detect, or 
prevent an associated misuse [64, 65]. This Security Use Case represents the system’s 
method of dealing with the vulnerabilities the Misuse Case exploited within the system. 
By analyzing the interactions of Use and Misuse, and then the associated Security Use 
Case-we can develop better system requirements that will prevent security breaches and 
provide some type of safety guarantee for our information. In this instance, the Misuse 
Case we presented exposes that we have an information flow and more importantly an 
information leakage problem within our system. The detection and mitigation of this 
leakage requires a change to the system architecture to account for the Security Use 
Case’s handling of the Use and Misuse Cases. The primary means to eliminate this 
misuse is via the rerouting of information in the system, as well as adding a new 
architectural element; the Information Declassifier. The detection of queries and alerts 
within the system must be supported by changing the architecture. The revised system 
architecture for the Security Use Case is shown in Figure 18 and Figure 19. For all 
system data queries, the Information Broker must provide filtered information contained 
in higher level IB alerts (or parts of information from those alerts that need to be shared 
with the levels below) that need to be read by the lower levels, and inject them into the 
lower level data query so that the covert channels created by the missing-information will 
not be there. The process can be done in two stages: 

1. The views and queries available to the lower levels (i.e.. Secret level) will 
be made available to the Top Secret level at design time. 

2. Create information downgrading rules between each (High, Low) level 
pair. 
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This allows the information that the lower classification level user is authorized to 
view to still be viewable (through the Alert and use of the Information Declassifier), 
instead of suspiciously absent because a higher classification level user “touched” the 
data and now they cannot Read it (even though it is within the scope and permissions of 
their Role’s duties). This provides a user with inference ability through the lack of 
information resultant from an authorized query to the system. 


Actoris/sci 



putes the 
between 
jlswer and 
^formation 


Port of 
Shanghai 


Figure 18. Graphical Representation of Security Use Case System Architecture 
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Figure 19. Security Use Case for IB System Architecture 

The removal of higher clearance level attributes is essential to maintaining the 
safety of the system and hinges on the lower level IB checking with a higher level IB. 
Each IB must successively iterate the query upward until the highest level IB is reached. 
This is, most likely, the global instance of the Top Secret IB. It is this IB that will give 
the authoritative answer when lesser IBs ask how to respond to queries. This IB will have 
to inject the presence of the GlobalstarV from the Port of Shanghai, in order to prevent 
this inference disclosure. This information injection will originate from the original Alert 
that is processed by the system during the execution of the EWO’s duties and obligations 
to report on specified criteria. But, it cannot just use the entire alert message and must 
filter the contents of the message based on role permissions for the user who executed the 
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initial query that have been mapped to the user’s role and validated with the PDP. The 
detailed Security Use Case is presented in Table 8, Table 9, Table 10, and Table 11. 

Table 8. High Level Alert Security Use Case (Alert Detection) 


Item 

Contents 

Use Case Name 

SUl-High Level Alert Security Use Case 

Actors 

EWO, Harbormaster 

Brief description 

Three sub-cases exist for this Security Use Case where the 
system must <detect> interactions at different touch points. 
These sub-cases include: 

1. The system detects an Alert message is being posted 
from a user (at any level). 

2. The system detects a user query submitted to the 
Information Broker (at any level). Two sub-cases 
exist: positive presence of data, and negative 
presence of data. 

3. The system detects an Inter-IB query (a lower level 
IB queries to a higher level IB). Two cases exist: 
positive presence of alert messages pertaining to the 
query, and negative presence of alert messaging 
pertaining to the query. 

Flow of events 

1. The system <detects> an Alert message and begins 
processing lAW SU1.1 

Alternative flow of events 

1. The system <detects> a query and begins processing 
lAW SU1.2 (User-IB) or SU1.3 (Inter-IB) 

Precondition 

Users of the use and misuse cases are authorized users of the 
system and have valid roles (EWO and Harbormaster) 
established in the system with a common subset of 
permissions mapped from the roles. 

Access to the system is available to all users. 

Post-condition 

User is authorized user of the system and has a valid role 
established in the system. 
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Table 9. High Level Alert Security Use Case (Alert Detection) 


Item 

Contents 

Use Case Name 

SU 1.1-High Level Alert Security Use Case (Alert Detection) 

Actors 

EWO, Harbormaster 

Brief description 

The system detects an Alert message is being posted and (a) 
examines the message for its distribution (b) maps 
permissions from the distribution roles (those who it is 
intended for) for accesses to those fields that are contained in 
the message thru multiple queries to the PDP (one query for 
each role / user on the distribution list) (c) removes parts of 
the message (data fields) that are not permitted for the roles 
permission mapping (d) transmits the message to the roles 
listed in the distribution. 

Flow of events 

1. An Alert message is posted to the system and stored 
at the current user’s classification level. 

2. The distribution list (recipients) of the message is 
examined. 

3. Each recipient is checked (by role) with the PDP for 
permissions on that message by field. 

4. Individual fields and data are filtered from the 
message based on the returned permission set (this 
could be an empty set). 

5. Message is delivered to intended recipients with 
unauthorized content filtered. 

Alternative flow of 
events 

1. An Alert message is posted to the system 

2. The distribution list (recipients) of the message is 
examined. 

3. Each recipient is checked (by role) with the PDP for 
permissions on that message by field. 

4. Individual fields and data are filtered from the 
message based on the returned permission set 
(this could be an empty set). 

5. Message contains no data available for delivery to a 
user and is stored at the current classification level. 

Precondition 

Users of the use and misuse cases are authorized users of the 
system and have valid roles (EWO and Harbormaster) 
established in the system with a common subset of 
permissions mapped from the roles. 

Access to the system is available to all users. 

Post-condition 

User is authorized user of the system and has a valid role 
established in the system. 
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Table 10. High Level Alert Security Lfse Case (User-IB Query Detection) 


Item 

Contents 

Use Case Name 

SUl.2-High Level Alert Security Use Case (User-IB 
Query Detection) 

Actors 

EWO, Harbormaster 

Brief description 

There are two alternative flows for this Use Case. 

The system detects a query has been submitted by a user 
to the Information Broker and (a) checks for validity of 
the query based on permissions mapped to the user role 
with a permission query to the PDF (b) checks with the 
higher level Information Broker for Alert messages that 
pertain to fields or values in the query that were 
validated by the PDP permission response (c) removes 
(filters) information from the query that is not permitted 
for viewing by the role of the requestor (d) provides the 
remaining information from the alert to the lower level 

IB (e) queries its own current level repositories for 
additional data matching the query and allowable for the 
role based permissions (f) aggregates the items from (d) 
and (e) to provide data to the user that is allowable via 
the role permissions assigned to the user. 

Alternatively, the system detects a query has been 
submitted by a user to the Information Broker and (a) 
checks for validity of the query based on permissions 
mapped to the user role with a permission query to the 
PDP (b) checks with the higher level Information Broker 
for Alert messages that pertain to fields or values in the 
query that were validated by the PDP permission 
response (c) negative response for alert message 
presence to the lower level IB (d) queries its own 
current level repositories for additional data 
matching the query and allowable for the role based 
permissions (e) provides data matching the query and 
allowable via the role permissions assigned to the 
user. 

Flow of events 

1. The system detects a query has been submitted 
by a user to the Information Broker 

2. Checks for validity of the query based on 
permissions mapped to the user role with a 
permission query to the PDP 

3. Generates an Inter-IB query, which checks with 
the higher level Information Broker for Alert 
messages that pertain to fields or values in the 
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Item 

Contents 


query that were validated by the PDP permission 
response 

4. Removes (filters) information from the query that 
is not permitted for viewing by the role of the 
requestor 

5. Queries its own current level repositories for 
additional data matching the query and allowable 
for the role based permissions 

6. Aggregates the Inter-IB query response with the 
original query response at the current IB level to 
provide data to the user that is allowable via the 
role permissions assigned to the user. 

Alternative flow of events 

1. The system detects a query has been submitted 
by a user to the Information Broker 

2. Checks for validity of the query based on 
permissions mapped to the user role with a 
permission query to the PDP 

3. Generates an Inter-IB query that checks with the 
higher level Information Broker for Alert 
messages that pertain to fields or values in the 
query that were validated by the PDP permission 
response 

4. Receives a negative response for alert message 
presence from the Inter-IB query 

5. Runs the original query against its own current 
level repositories for data matching the query and 
allowable for the role based permissions 

Provides data matching the query and allowable via the 
role permissions assigned to the user or provides a 
negative response to the user for the data query. 

Precondition 

Users of the use and misuse cases are authorized users of 
the system and have valid roles (EWO and 

Harbormaster) established in the system with a common 
subset of permissions mapped from the roles. 

Access to the system is available to all users. 

Post-condition 

User is authorized user of the system and has a valid role 
established in the system. 
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Table 11. High Level Alert Security Lfse Case (Inter-IB Query Detection) 


Item 

Contents 

Use Case Name 

SUl.3-High Level Alert Security Use Case (Inter-IB 

Query Detection) 

Actors 

EWO, Harbormaster 

Brief description 

The system detects an query from a lower level IB to a 
higher level for alert message data (which includes role and 
permission information) and (a) submits a similar type 
query to its higher level IB (hi) aggregates a positive 
response with any additional alert messages that exist at its 
own level or (b2) after a negative response from a higher 
level the IB queries its own level for alert message 
information pertaining to the query and allowable via the 
role permissions (c) provides either a negative response to 
the lower level IB or the resultant data from (bl) or (b2) to 
the lower level IB. 

Flow of events 

1. The system detects an Inter-IB query from a lower 
level IB to a higher level for alert message data 
(which includes role and permission information) 

2. Submits a similar type query to its higher level IB 
(unless it is the authoritative IB) 

3. Aggregates a positive response to the Inter-IB 
query with any additional alert messages that exist 
at its own level 

4. Filters the information not permissible for the 
user’s role permission set. 

5. Provides the resultant data set from the query to 
the lower level IB. 
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Item 

Contents 

Alternative flow of events 

1. The system detects an Inter-IB query from a lower 
level IB to a higher level for alert message data 
(which includes role and permission information) 

2. Submits a similar type query to its higher level IB 
(unless it is the authoritative IB) 

3. Receives a negative response from a higher level 

and then queries its current level for alert message 
information pertaining to the query and allowable 
via the role permissions 

4. Filters the information not permissible for the 
user’s role permission set. 

5. Provides either a negative response to the lower 
level IB if the permission to data mapping is empty. 

6. Provides a filtered result of the data set to the lower 
level IB. 

Precondition 

Users of the use and misuse cases are authorized users of 
the system and have valid roles (EWO and Harbormaster) 
established in the system with a common subset of 
permissions mapped from the roles. 

Access to the system is available to all users. 

Post-condition 

User is authorized user of the system and has a valid role 
established in the system. 


4. Impact of Misuse and Mitigation 

Overall, the Misuse Case exposes an information flow and more importantly an 
information leakage problem within our system. The leakage is an inference about cross¬ 
domain information. The detection and mitigation of this leakage requires a change to the 
system architecture to account for the Security Use Case’s handling of the Use and 
Misuse Cases. The primary means to eliminate this misuse is via the rerouting of 
information in the system, as well as adding a new architectural element; the Information 
Declassifier. The ID must act as an intermediary between varying security domains, 
represented by an Information Broker (IB), to process queries from lower classification 
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levels and to pull data pertaining to Alert Notifications from higher classification level 
data stores. This is necessary, because, if a higher level user touches the data pertaining to 
a VOI, the lower level user can no longer view that data, that they are entitled to (in 
performance of their duties to fulfill a Role). In order to prevent such security violations. 
Radiant Alloy needs to use an information declassifier. In this research, we provide a 
policy-based framework to do so using RuleML. 

This revised system architecture is a proposed goal of this research and is shown 
in Figure 20. It is in this re-architecting that we have rerouted all system queries from 
both users and existing domain level information brokers, in order to prevent the misuse 
of our system. Although this figure depicts a singular Information Declassifier (ID), we 
must provide for ID replication throughout the system and particularly between each 
information domain. 
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Figure 20. Graphical Representation of System Architecture for Leakage Mitigation 
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Because of this inter-domain requirement, the ID serves as a proxy for all 
messaging within the system. It is here where the ID will take cleared messages and 
include them in referenced queries, to which the lower level IB itself should not see 
outright (because of BLP’s Simple Security Property). This use of an Information 
Declassifier adds complexity to our system design and requires additional interactions 
between domain level information brokers. Between each domain we must have an ID 
residing to request and deliver information from higher domains. This will be iterative 
from the lowest IB domain level (e.g., Unclassified) up to the highest level IB domain 
(e.g.. Top Secret), where an ID will be able to query for Alert notifications (or other data) 
and be able to provide that as required to a lower level IB domain. A state chart 
representation of the query and alert process with the interactions between separate IBs 
and an ID is shown in Figure 21. The start state is denoted by the solid black circle, the 
arrows indicate transition flow, and the double circles, which encompass the IBs and ID 
denote accepting states within the statechart. 



Figure 21. Statechart for Information Broker and Information Declassifier Process 
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As each query is received at an individual domain’s IB, the individual IB will first 
perform its duties to authenticate the user, and the user’s permissions for the requested 
data, based on both the user’s role permission set and the classification level of the 
information. After a query is acknowledged as valid within the IB, the IB will forward 
the user query to the ID, where it will then check with the higher level IB for information 
pertaining to that user query. The request to the higher level domain IB does not query 
the higher level data stores for new information, but merely checks for Alert messages 
within the system that pertain to a particular role or other mapping which we can 
establish through the rules that are expressed in the Information Declassifier. Each IB, 
upon receiving an ID request, will check with a higher level ID until the highest domain 
level of the system is reached. At each domain level upon an ID query, the information 
broker will check its Alert messaging stores and provide either a positive response with 
the information or a negative response with no data. This will aggregate downward until 
the originating IB is reached. It is then that the IB will inject any alert response data with 
its own query response from domain level data fulfilling the user query. Information 
markings are not depicted in this flow, but the Information Broker is responsible for 
adding appropriate markings (at each security level) for any data that does not already 
contain markings. This will be appended to the data before the IB will return a response 
to a user 

In this proposed architecture, we have no violation of BLP-since we have no 
write down, nor do we violate the RBAC policy within our classification domains. There 
is no indirect means of obtaining information either, since RBAC ensures that we are not 
seeing anything that the Role does not allow for in the first place (nothing that the actor is 
not already entitled to). The Harbormaster is entitled to examine information about ships 
that are entering his port. This is merely a cause of not being able to see information 
because a higher classification level entity last touched the data (where it cannot be 
written down *-Property) and he cannot read up to see it (Simple Security Property). As 
long as the system architecture is adhered to, the Information Declassifier will bridge the 
gap between classification levels without creating covert channels. 
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Making these changes to the system architecture requires several elements: 
detailed specification of the Information Declassifier and its actions (using RuleML) via 
domain-specific declassification policies and rules, representation of query translations, 
representation of system alert notifications, a revised definition of safety for our new 
architecture, and establishment of test cases that ensure the functionality of the Use Cases 
and prevent the Misuse Cases within the re-architected system. From this we can regain 
the Safety of our information flows within the system and prevent information leakage 
between domains for all future system that adhere to our re-architecting efforts. 

5. Conclusion 

This Use-Case analysis and its application demonstrate the criticality of 
architecting an information broker that is integrated with the security requirements for 
high-assurance, while also maintaining the core functionality of the system without 
degradation. In general, we design a system to meet specific requirements as they are 
provided by a scenario that we wish to support. It is from these requirements that we 
generate a desired policy that we want to enact within the system, and as a result, we 
select an access control or security model that most closely approximates the intended 
policy. In the policy that is created, we expect to achieve a safety of information flows by 
using an established security model. By mapping the policy to the model and then 
extending our safety analysis from the underlying model to the overarching security 
policy, we can provide a safety guarantee for our system. It is with this safety guarantee 
in mind, that the designers select an architecture and begin the implementation of the 
associated security policy. 

By integrating the security requirements when deciding on an access control model, 
and, in this case, using a mixed access control model, while developing a rule set for 
integration to our security policy to prevent the described Misuse cases. The execution of 
the Security Use Case will originate with the Information Declassifier and the rules 
associated with its use as they are mapped to the Use and Misuse Cases for the desired 
system behaviors to maintain the safety property. 
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V. QUERY AND ALERT MESSAGING 


A. XML DATA SET 

In Radiant Alloy, users are able to enter queries to the Information Broker that 
correspond to information or data required for their role. A representation of that data 
found in Radiant Alloy, can be expressed using extensible Markup Language (XML). In 
order to examine how this query ability could be influenced with the use of an ID, we 
have created a sample subset of XML data for vessel information and alert messages 
supporting our Use-Case scenario, for demonstrating the ability of the Use-Case analysis 
and ID rule generation to be extended to other scenarios. 

Within the U.S. government, information markings are Defense Message System 
(DMS) General Service (GENSER) message classifications, categories and markings 
[66]. These have been added to the IB mechanism, which will actually perform the 
formal access control and apply classification, category, and dissemination control 
markings to data as it is pulled from repositories as appropriate. In this sample, data the 
marking field has been added and populated to provide the ability to parse queries 
appropriate for varying domains without the actual implementation of a multi-domain, 
replicated IB. The proper implementation of these marking requirements is to provide 
interoperability with respect to security classifications and categories of DMS GENSER 
messaging. Information regarding the sensitivity level and markings associated with 
message content needs to be conveyed to the user requesting information from the 
system. Additionally, the markings are required so that access control decisions can be 
made. 

There are generally two methods for storing XML data in a repository. The first 
case is to utilize individual files for each element being described (i.e., a separate file for 
each vessel). While the second option is to establish a larger, single file with a parent 
element and list child elements inside (i.e., <VESSELS> as the parent element containing 
a <VESSEL> tag for each ship). The multiple file instance is more complex with respect 
to storage and querying, and the single storage instance is merely a degenerate case. In 
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this example, we used the single document instance for both the Alerts and Vessels, as 
the method of storage does not impact the ability to exercise the rules of the ID. 

1. Vessel Information 

The vessel information used for this sample system is based on the Automatic 
Identification System (AIS). AIS provides the means for ships to electronically exchange 
data with other nearby ships and Vessel Traffic Services stations. AIS was developed to 
assist the vessel’s watch officers with a standardized information schema and allow 
maritime authorities to track ships. The AIS uses a vessel’s on-board navigational 
instruments to provide the data. This system reliably transmits information about vessels 
and ship tracking at fixed intervals of time. Certain information, such as the Maritime 
Mobile Service Identity (MMSI), Navigation Status, Speed, Latitude, Longitude, 
Heading, and Time Stamp, are transmitted every 2-10 seconds (depending upon speed) 
while underway and every 3 minutes while at anchor. Additional and less variable 
information is transmitted every 6 minutes, to include the IMO Number, Call Sign, 
Length, Width, Destination, and Estimated Arrival Time. The XML data code used in the 
Vessel.xml is shown in Listing 1. 


<?xml version="l . 0" encoding="UTF-8" standalone="yes" ?> 
<VESSELS> 

<TITLE>Vessel Report</TITLE> 

<MESSAGE> 

<![CDATA[ 

Listing of vessels resulting from your query. 

] ]> 

</MESSAGE> 

<!— Sample Vessel used in Use Case: —> 

<VESSEL> 

<!— Sample tracking data for vessels 
—> 

<NAME_TXT>Name : </NAME_TXT> 
<NAME>Globalstar7</NAME> 

<MMSI_TXT>MMSI : </MMSI_TXT> 
<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>Shanghai</ORIGINATING_PORT> 
<TYPE>Commercial Vessel</TYPE> 
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<SUB_TYPE>Container Ship</SUB_TYPE> 

<DEPARTURE>8/28/08 08: 45</DEPARTURE> <!— UTC / month/date/year 
hour:minute —> 

<!— AIS sends the following data every 2-10 seconds while underway 
depending on speed, and every 3 minutes while at anchor 

—> 

<MMSI>412159177</MMSI> <!— Maritime Mobile Service Identity 

412, 413 China —> 

<NAV_STATUS>Under Way Using Engines</NAV_STATUS> <!— At Anchor, 
Under Way, etc. —> 

<RATE_OF_TURN>0</RATE_OF_TURN> <!— Right or Left, 0-720 degrees 
per minute —> 

<SPEED_OVER_GROUND>10 .2 Knots</SPEED_OVER_GROUND> <!— 0 to 102 
Knots, 0.1 increments —> 

<POSITION_ACCURACY>3 Meters</POSITION_ACCURACY> 

<LATITUDE>27 . 147145</LATITUDE> 

<LONGITUDE>-128 . 342285</LONGITUDE> 

<COURSE_OVER_GROUND></COURSE_OVER_GROUND> <!— relative to true N 
to 0.1 degree —> 

<TRUE_HEADING>27</TRUE_HEADING> <!— 0 to 359 degrees from 
gyro compass —> 

<TIME_STAMP></TIME_STAMP> <!— UTC time stamp for data —> 

<!— AIS broadcasts the following data every 6 minutes 
—> 

<IMO_NUMBER>IMO 12345 67</IMO_NUMBER> <!— # unchanged upon 
transfer of registry —> 

<RADIO_CALL_SIGN>G7CSl</RADIO_CALL_SIGN> <!— up to seven 
characters —> 

<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> <!— GPS, DGPS, 
LORAN-C —> 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>San Diego</DESTINATION_PORT> <!— Max 20 
characters —> 

<EST_ARRIVAL>10/l/08 13: 00</EST_ARRIVAL> <!— UTC / 
month/date/year hour:minute —> 

<CLASSIFICATION>Top Secret</CLASSIFICATION> 
<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL> <!— —> 

<!— Sample Vessel used in Use Case: —> 

<VESSEL> 

<!— Sample tracking data for vessels 
—> 

<NAME_TXT>Name : </NAME_TXT> 

<NAME>USS ANTIETAM</NAME> 

<MMSI_TXT>MMSI : </MMSI_TXT> 

<REGISTRY>USA</REGISTRY> 

<MILITARY>YES</MILITARY> 

<ORIGINATING_PORT>San Diego</ORIGINATING_PORT> 

<TYPE>Military Vessel</TYPE> 
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<SUB_TYPE>CG-54</SUB_TYPE> 

<DEPARTURE>0/0/00 00: 00</DEPARTURE> <!— UTC / month/date/year 
hour:minute —> 

<!— AIS sends the following data every 2-10 seconds while underway 
depending on speed, and every 3 minutes while at anchor 

—> 

<MMSI>36677900</MMSI> <!— Maritime Mobile Service Identity 366 

U.S. —> 

<NAV_STATUS>Under Way Using Engines</NAV_STATUS> <!— At Anchor, 
Under Way, etc. —> 

<RATE_OF_TURN>Right 5</RATE_OF_TURN> <!— Right or Left, 0-720 
degrees per minute —> 

<SPEED_OVER_GROUND>25 .7 Knots</SPEED_OVER_GROUND> <!— 0 to 102 
Knots, 0.1 increments —> 

<POSITION_ACCURACY>3 Meters</POSITION_ACCURACY> 

<LATITUDE>25 .09554 9</LATITUDE> 

<LONGITUDE>-137 . 625732</LONGITUDE> 

<COURSE_OVER_GROUND>57 . 6</COURSE_OVER_GROUND> <!— relative to 
true N to 0.1 degree —> 

<TRUE_HEADING>57 . 8</TRUE_HEADING> <!— 0 to 359 degrees 
from gyro compass —> 

<TIME_STAMP>9/28/08 14: 17</TIME_STAMP> <!— UTC time stamp for 
data —> 

<!— AIS broadcasts the following data every 6 minutes 
—> 

<IMO_NUMBER>IMO 765432 1</ IMO_NUMBER> <!— # unchanged upon 
transfer of registry —> 

<RADIO_CALL_SIGN>CGA2X54</RADIO_CALL_SIGN> <!— up to seven 
characters —> 

<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> <!— GPS, DGPS, 
LORAN-C —> 

<LENGTH>250</LENGTH> 

<WIDTH>32</WIDTH> 

<DRAUGHT>30</DRAUGHT> 

<DESTINATION_PORT>Not Reported</DESTINATION_PORT> <!— Max 20 
characters —> 

<EST_ARRIVAL>0/0/00 00: 00</EST_ARRIVAL> <!— UTC / month/date/year 
hour:minute —> 

<CLASSIFICATION>Unclassified</CLASSIFICATION> 

<ALERT_PRESENT>No</ALERT_PRESENT> 

</VESSEL> <!— —> 

<VESSEL> 

<!— Sample tracking data for vessels 

—> 

<NAME_TXT>Name : </NAME_TXT> 

<NAME>Globalstar2</NAME> 

<MMSI_TXT>MMSI : </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>Shanghai</ORIGINATING_PORT> 

<TYPE>Commercial Vessel</TYPE> 
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<SUB_TYPE>Container Ship</SUB_TYPE> 

<DEPARTURE>9/15/08 02: 45</DEPARTURE> 

<!— UTC / month/date/year hour:minute —> 

<!— AIS sends the following data every 2-10 seconds while underway 
depending on speed, and every 3 minutes while at anchor 

> 

<MMSI>412159197</MMSI> 

<!— Maritime Mobile Service Identity 412, 413 China —> 
<NAV_STATUS>Under Way Using Engines</NAV_STATUS> 

<!— At Anchor, Under Way, etc. —> 

<RATE_OF_TURN> 0 < /RATE_OF_TURN> 

<!— Right or Left, 0-720 degrees per minute —> 
<SPEED_0VER_GR0UND>11 .2 Knots</SPEED_OVER_GROUND> 

<!— 0 to 102 Knots, 0.1 increments —> 

<POSITION_ACCURACY>3 Meters</POSITION_ACCURACY> 

<LATITUDE>47 . 147145</LATITUDE> 

<LONGITUDE>-121 . 342285</LONGITUDE> 

< COURSE_OVER_GROUND ></ COURSE_OVER_GROUND > 

<!— relative to true N to 0.1 degree —> 
<TRUE_HEADING>67</TRUE_HEADING> 

<!— 0 to 359 degrees from gyro compass —> 

<TIME_STAMP>9/28/08 09:4 9</TIME_STAMP> 

<!— UTC time stamp for data —> 

<!— AIS broadcasts the following data every 6 minutes 

> 

< IMO_NUMBER> IMO 1234561</ IMO_NUMBER> 

<!— # unchanged upon transfer of registry —> 

< RAD10_CAL L_SIGN>G2CS1</ RAD10_CALL_SIGN > 

<!— up to seven characters —> 
<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> 

<!— GPS, DGPS, LORAN-C —> 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>San Diego</DESTINATION_PORT> 

<!— Max 20 characters —> 

<EST_ARRIVAL>10/2/08 15: 00</EST_ARRIVAL> 

<!— UTC / month/date/year hour:minute —> 

<CLASSIFICATION>Unclassified</CLASSIFICATION> 

<ALERT_PRESENT>No</ALERT_PRESENT> 

</VESSEL> 

<!— —> 

<VESSEL> 

<!— Sample tracking data for vessels 

> 

<NAME_TXT>Name : </NAME_TXT> 

<NAME>Globalstar8</NAME> 

<MMSI_TXT>MMSI : </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>San Diego</ORIGINATING_PORT> 

<TYPE>Commercial Vessel</TYPE> 
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<SUB_TYPE>Container Ship</SUB_TYPE> 

<DEPARTURE>9/27/08 21: 15</DEPARTURE> 

<!— UTC / month/date/year hour:minute —> 

<!— AIS sends the following data every 2-10 seconds while underway 
depending on speed, and every 3 minutes while at anchor 

—> 

<MMSI>412159178</MMSI> 

<!— Maritime Mobile Service Identity 412, 413 China —> 
<NAV_STATUS>Under Way Using Engines</NAV_STATUS> 

<!— At Anchor, Under Way, etc. —> 

<RATE_OF_TURN> 0 < /RATE_OF_TURN> 

<!— Right or Left, 0-720 degrees per minute —> 
<SPEED_OVER_GROUND>15 .6 Knots</SPEED_OVER_GROUND> 

<!— 0 to 102 Knots, 0.1 increments —> 

<POSITION_ACCURACY>3 Meters</POSITION_ACCURACY> 

<LATITUDE>37 . 147145</LATITUDE> 

<LONGITUDE>-18 . 342285</LONGITUDE> 

< COURSE_OVER_GROUND ></ COURSE_OVER_GROUND > 

<!— relative to true N to 0.1 degree —> 
<TRUE_HEADING>98</TRUE_HEADING> 

<!— 0 to 359 degrees from gyro compass —> 

<TIME_STAMP>9/28/08 14: 45</TIME_STAMP> 

<!— UTC time stamp for data —> 

<!— AIS broadcasts the following data every 6 minutes 

—> 

< IMO_NUMBER> IMO 1234568</ IMO_NUMBER> 

<!— # unchanged upon transfer of registry —> 

< RAD10_CAL L_SIGN>G8CS1</ RAD10_CALL_SIGN > 

<!— up to seven characters —> 
<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> 

<!— GPS, DGPS, LORAN-C —> 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>Oakland</DESTINATION_PORT> 

<!— Max 20 characters —> 

<EST_ARRIVAL>10/5/08 19: 30</EST_ARRIVAL> 

<!— UTC / month/date/year hour:minute —> 

<CLASSIFICATION>Unclassified</CLASSIFICATION> 

<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL> 

<!— —> 

</VESSELS> 

Listing 1. XML Code for Vessels.xml 


This code represents a small-scale sample of the type of data that might be 
available in a production level Radiant Alloy system that is connected into real-time 
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repositories and reporting systems based on the National Information Exchange Model 
(NIEM) [9]. By using this sample XML code as a foundation, we can test a live query 
based request for data and the integration of the ID used in the re-architecting of our 
system with existing alerts. 

1. Alert Messages 

System Alert Notifications are added to the replicated domain-level IBs as the 
notifications are archived and retrieved. Alert Notification messages are based on the 
standard maritime Advance Notice of Arrival (ANOA) and use the XML-based Maritime 
Information Exchange Model (MIEM) [5]. The alert includes fields from a standard 
Vessel Activity Report (VAR) to show details such as identification, kinematics, and port 
history, as well as the specific instructions pertaining to the alert. In our scenario, the 
EWO processes an Alert Notification about the GlobalstarV, as he or she updates some 
part of the VAR data for that vessel, thus causing the VAR to “disappear” from the lower 
level (Unclassified) view in the system. 

These Alert messages become a critical piece of the Use-Case scenario that was 
presented. As vessels are processed in the system as Vessels of Interest (VOI), alerts are 
generated. These alerts are processed at whichever classification level they originate from 
(e.g.. Top Secret), and the role of the IB will be extended to both distribute and query 
these alerts as the system is used. Since each alert contains information pertaining to a 
specific vessel, port, and time group, we can effectively query the XML-based 
information in the same manner as we would any other data. This allows a seamless 
integration with our ID and our domain-level IBs to process queries based on Vessel and 
Alert Message details. Our Use-Case scenario dictates that valid Alert Messages will be 
generated to notify ports or facilities of pertinent information. These Alerts will include 
the following: 

• To Information (a Port or a Role can be used in this field) 

• Date Time Group (DTG) of the Alert generation 

• Suspense for action on the Alert 
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• special instractions or Comments regarding the message 

• Vessel of Interest (VOI) information 

As the Electronic Warfare Officer (EWO) performs his duties, he is responsible for the 
generation of Alert Messages. These messages are intended to facilitate port security and 
homeland defense, and the EWO has the responsibility of transmitting the Alert Message 
through the system. Listing 2 shows a sample alert message XML file was generated for 
the High Level Alert Use-Case scenario. 


<?xml version="l . 0" encoding="utf-8" ?> 
<?xml-stylesheet type="text/css" href="alert.css" ?> 
<?xml-stylesheet type="text/css" href="vessels.css" ?> 


<ALERTS> 

<TITLE>ALERT Notificat ion</TITLE> 

<MESSAGE> 

<! [CDATA[ 

Alert for a Vessel of Interest (VOI). 

] ]> 

</MESSAGE> 

<!— Alert format for Use Case: —> 

<ALERT> 

<ALERT_TO>San Diego</ALERT_TO> 

<ALERT_DTG>9/28/08 05: 00</ALERT_DTG> 

<SUSPENSE>10/ 01/08 23:5 9</ SUSPENSE> 

< COMMENT S> 

<![CDATA[ 

VOI — notify local CG Office @ (619) 867-5309 upon arrival and 

inspect cargo with CG Duty Officer 

] ]> 

</ COMMENT S> 

<VESSEL> 

<!— Sample tracking data for vessels 
—> 

<NAME_TXT>Name : </NAME_TXT> 

<NAME>Globalstar7</NAME> 

<MMSI_TXT>MMSI : </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>Shanghai</ORIGINATING_PORT> 

<TYPE>Commercial Vessel</TYPE> 

<SUB_TYPE>Container Ship</ SUB_TYPE> 

<DEPARTURE>8/28/08 08:4 5</DEPARTURE> <!— UTC / month/date/year 
houriminute —> 

<!— AIS sends the following data every 2-10 seconds while 

underway 
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depending on speed, and every 3 minutes while at anchor 

—> 

<MMSI>412159177</MMSI> <!— Maritime Mobile Service Identity 412, 

413 China —> 

<NAV_STATUS>Under Way Using Engines</NAV_STATUS> <!— At Anchor, 
Under Way, etc. —> 

<RATE_OF_TURN>0</RATE_OF_TURN> <!— Right or Left, 0-720 degrees 
per minute —> 

<SPEED_OVER_GROUND>10 .2 Knots</SPEED_OVER_GROUND> <!— 0 to 102 
Knots, 0.1 increments —> 

<POSITION_ACCURACY>3 Meters</POSITION_ACCURACY> 

<LATITUDE>27 . 147145</LATITUDE> 

<LONGITUDE>-128 .3422 85</LONGITUDE> 

<COURSE_OVER_GROUND></COURSE_OVER_GROUND> <!— relative to true N 
to 0.1 degree —> 

<TRUE_HEADING>27</TRUE_HEADING> <!— 0 to 359 degrees from 
gyro compass —> 

<TIME_STAMP></TIME_STAMP> <!— UTC time stamp for data —> 

<!— AIS broadcasts the following data every 6 minutes 
—> 

<IMO_NUMBER>IMO 1234567 </ IMO_NUMBER> <!— # unchanged upon 
transfer of registry —> 

<RADIO_CALL_SIGN>G7CSl</RADIO_CALL_SIGN> <!— up to seven 

characters —> 

<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> <!— GPS, DGPS, 

LORAN-C —> 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>San Diego</DESTINATION_PORT> <!— Max 20 
characters —> 

<EST_ARRIVAL>10/l/08 13: 00</EST_ARRIVAL> <!— UTC / 
month/date/year houriminute —> 

<CLASSIFICATION>Top Secret </CLASSIFICATION> 
<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL> <!— —> 

</ALERT> 

<!— Alert format for Use Case: —> 

<ALERT> 

<ALERT_TO>Oakland</ALERT_TO> 

<ALERT_DTG>10/02/08 05: 00</ALERT_DTG> 

<SUSPENSE>10/06/08 23:5 9</ SUSPENSE> 

<COMMENTS> 

<![CDATA[ 

VOI — call Dr. Falken from Protovision at 555-8632, also alert 
INS and local CG 

] ]> 

</ COMMENT S> 

<VESSEL> 

<!— GlobalstarS 

— > 

<NAME_TXT>Name : </NAME_TXT> 

<NAME>Globalstar8</NAME> 

<MMSI_TXT>MMSI : </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 
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<ORIGINATING_PORT>San Diego</ORIGINATING_PORT> 

<TYPE>Commercial Vessel</TYPE> 

<SUB_TYPE>Container Ship</ SUB_TYPE> 

<DEPARTURE>9/27/08 21 : 15</DEPARTURE> 

<!— UTC / month/date/year hour:minute —> 

<!— AIS sends the following data every 2-10 seconds while underway 
depending on speed, and every 3 minutes while at anchor 

—> 

<MMSI>412159178</MMSI> 

<!— Maritime Mobile Service identity 412, 413 China —> 
<NAV_STATUS>Under Way Using Engines</NAV_STATUS> 

<!— At Anchor, Under Way, etc. —> 

<RATE_OE_TURN> 0 </ RATE_OE_TURN> 

<!— Right or Left, 0-720 degrees per minute —> 
<SPEED_OVER_GROUND>15 .6 Knots</SPEED_OVER_GROUND> 

<!— 0 to 102 Knots, 0.1 increments —> 

<POSITION_ACCURACY>3 Meters</POSITION_ACCURACY> 

<LATITUDE>37 . 147145</LATITUDE> 

<LONGITUDE>-18 .3422 85</LONGITUDE> 
<COURSE_OVER_GROUND></COURSE_OVER_GROUND> 

<!— relative to true N to 0.1 degree —> 

< TRUE_HEADING> 9 8 </ TRUE_HEADING> 

<!— 0 to 359 degrees from gyro compass —> 

<TIME_STAMP>9/28/08 14: 45</TIME_STAMP> 

<!— UTC time stamp for data —> 

<!— AIS broadcasts the following data every 6 minutes 

— > 

< IMO_NUMBER> IMG 1234568</ IMO_NUMBER> 

<!— # unchanged upon transfer of registry —> 
<RADIO_CALL_SIGN>G8CSl</RADIO_CALL_SIGN> 

<!— up to seven characters —> 
<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> 

<!— GPS, DGPS, LORAN-C —> 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>Oakland</DESTINATION_PORT> 

<!— Max 20 characters —> 

<EST_ARRIVAL>10/5/08 19: 30</EST_ARRIVAL> 

<!— UTC / month/date/year houriminute —> 

<CLASSIEICATION>Unclassified</CLASSIEICATION> 

<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL> 

<!— —> 

</ALERT> 

</ALERTS> 

Listing 2. XML Code for Alerts.xml 


Despite having only two alerts in the sample data store, we can still show the 
ability to parse through the data for alerts that pertain to specific locations and provide a 
basis for the testing of our query engine and the resultant ID rules that are created to 
specify our security policy. In our High Level Alert Use-Case scenario, we find that the 
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EWO is at a higher classification level (i.e.. Top Secret), than the Harbormaster to whom 
the Alert Message is intended. Since the EWO is operating in a different domain than the 
Harbormaster, when he touches information in the system, by marking the GlobalstarV as 
a VOI, he effectively prevents all lower classification users from seeing this track (due to 
the tranquilty property of BLP). This is where the unintended creation of information 
leakage arises when the Harbormaster becomes alerted to the presence of a ship in the 
system that he cannot access information pertaining to from his resultant queries. 

B. QUERIES 

Several methods exist for generating queries and controlling access to data stores 
based on XML. These include XQuery and XPath, developed by the W3C [67]. 
XMLQuery, however, does not allow the modification of data and subsequent saving of 
the modified information back into the data store and is a deprecated version of XPath. 
User queries are a standard and integral service of the IB and are generated using Xpath. 
Each request for data (i.e., query) processed by the IB is first checked for permissions by 
the Policy Decision Point (PDP) service, then passed via a service call to the ID service 
associated with that classification level. The IB then begins execution of the query itself 
but must wait for a positive or negative response from the ID service before returning 
results to the user. Valid queries can be performed on any field available from an Alert 
Message or within a VAR. A sample Xpath query for the San Diego Harbormaster 
requesting a Destination Port query is shown in Listing 3. 

/VESSELS/VESSEL/DESTINATION_PORT[text()='San Diego'] 

Listing 3. Xpath Query for San Diego Harbormaster using Destination Port 

Integral to this query are the attributes for the user (role, location, security level, 
and time stamp) that are also passed with the query for use by both the IB and ID 
services. These attached attributes are critical to the IB’s response since the XPath query 
that is used for the EWO (Listing 4) is identical to the query from the Harbormaster. 

/VESSELS/VESSEL/DESTINATION_PORT[text 0 ='San Diego' ] 

Listing 4. Xpath Query for EWO using Destination Port of San Diego 
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The differences in the query return data are from the IB’s use of those additional 
attributes attached to the initial query. Figure 22 shows the XML data present for all 
vessels in the system and then the expected results from San Diego destination port 
queries for both the Harbormaster and the EWO. 


^ Sample Use-Case System Results - Internet EiqDlorer provided by Dell 

^ http;//localhGst;60072/WebQu ^ 

X ^ Google P 

^ ^ Sample Use-Case System Re... 

® ^ 0 ^ ^ T Tools ^ 


Querj^ for All Vessels 


Bestmation Port Est Arrival MMSI 


Name Orimnatine Port 


San Diego 10/1/08 13:00 4 12 1 59 1 7? Globalstar? Shanghai 

Not Reported 0/0/00 00:00 36677900 USS ANTIETAM San Diego 

San Diego 10/2/08 15:00 412159197 Globalstar2 Shanghai 

Oakland 10/5/08 19:30 412159178 Globalstar8 San Diego 


HjVI Query for v essels with Destination of ^ San Diego^ 


Bestination Port Est Arrival MMSI Name Originating^Port 


San Diego 


10/2/08 

15:00 


412159197 Globalstar2 


Shanghai 


EWQ Queiy for Vessels with Destination of ^'San PiegQ^' 


Bestination Port Est Arrival MMSI Name Originating Port 


San Diego 10/1/08 13:00 412159177 Globalstar? Shanghai 

San Diego 10/2/08 15:00 412159197 Global5tar2 Shanghai 


Figure 22. Expected XPath Query Results by Role 


In our High Level Alert Use-Case scenario, valid queries can be performed on any 
field available from an Alert Message or within Vessel details. The data set that the 
system returns must be restricted based upon Role permission for each of our actors in 
the scenario. In this case, the query and resultant data must include the Harbormaster’s 
port (either Origination or Destination) for details to be returned by the IB and ID. This 
will prevent a Harbormaster from just querying the system to get information about 

94 



































vessels from the system that do not directly pertain to his role (at his location) and his 
direct performance of duty. But, he should be entitled to know information about ships 
arriving or departing from his location, since this is a key responsibility of his job. 
Additionally, the Harbormaster should be able to query the system for the presence of 
Alert Messages that pertain to his role. These aspects are areas that must be enforced 
using the IB, but can only be done as a result of our re-architecting through the addition 
of an ID and its rule processing. 

This result is reflective of a standard query to the system and can be extended as 
necessary to support other scenarios. The XPath query can be used on both standard 
vessel data that is present in the system, as well as for Alert Messages that are present. 
Listing 5 depicts a sample Xpath query for Alert Messaging for the port of San Diego. 

/ALERTS/ALERT/DESTINATION_PORT[text()='San Diego'] 

Listing 5. Xpath Alert Messaging Query for San Diego Harbormaster 

While Listing 6 depicts the query that would be executed by the EWO for Alerts 
present at the TS level. This query would return all alerts present at his security level, 
since we are not restricting the EWO’s access because of his role. 

/ALERTS/ALERT 

Listing 6. Xpath Alert Messaging Query for EWO 
The expected results of both of these Alert Messaging queries are shown in Figure 23. 
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Figure 23. Expected XPath Query Alert Messaging Results by Role 


As an additional query method and to better support a web-enable test framework 
for query integration, we chose to utilize Language Integrated Query (LINQ) and 
integrate the queries using Visual Basic. It includes query, set, and transform operations 
via integrated library functions for data. LINQ to XML takes advantage of standard query 
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operators and adds query extensions specific to XML, as well as offering integration with 
RDF format data. Either of these query methods (XPath or LINQ) can exist in Radiant 
Alloy. The web page version could easily be modified to allow for easier manipulation of 
queries and access to the data, but in this example we relied on hard-coding of queries 
and singular executions to show that the query system is operational. A sample of the 
query system using LINQ is shown in Listing 7. 


Imports System.Xml.Linq 

Partial Class _Default 

Inherits System.Web.UI.Page 
Private xmlDocument As XDocument 

Protected Overrides Sub OnLoad(ByVal e As System.EventArgs) 

MyBase .OnLoad(e) 

LoadXMLDocument() 

GridViewl.DataSource = DescendantsQueryl() 

GridViewl.DataBind() 

GridView2.DataSource = DescendantsQueryS() 

GridView2.DataBind() 

Dim vesselListl As XDocument = 

XDocument.Load(MapPath( "vessels.xml" )) 

Dim alertListl As XDocument = 

XDocument.Load(MapPath( "alerts.xml" )) 

GridViewS.DataSource = From VESSEL In vesselListl...<VESSEL> 
Where VESSEL.<ORIGINATING_PORT>.Value = "San Diego" And 
VESSEL.<CLASSIFICATION>.Value = "Unclassified" Select Name = 

VESSEL.<NAME>.Value, MMSI = VESSEL.<MMSI>.Value, Est_Arrival = 

VESSEL.<EST_ARRIVAL>.Value, Originating_Port = 

VESSEL.<ORIGINATING_PORT>.Value, Destination_Port = 

VESSEL.<DESTINATION_PORT>.Value 
GridViewS.DataBind() 

GridViewS.DataSource = From VESSEL In vesselListl...<VESSEL> 
Where VESSEL.<DESTINATION_PORT>.Value = "San Diego" And 
(VESSEL.<CLASSIFICATION>.Value = "Top Secret" Or 
VESSEL.<CLASSIFICATION>.Value - "Unclassified") Select Name = 

VESSEL.<NAME>.Value, MMSI = VESSEL.<MMSI>.Value, Est_Arrival = 

VESSEL.<EST_ARRIVAL>.Value, Originating_Port = 

VESSEL.<ORIGINATING_PORT>.Value, Destination_Port = 

VESSEL.<DESTINATION_PORT>.Value 
GridViewS.DataBind() 

GridView4.DataSource = From ALERT Tn alertListl...<ALERT> 

Select Alert_To = ALERT.<ALERT_TO>.Value, Suspense = 

ALERT.<SUSPENSE>.Value, Comments = ALERT.<COMMENTS>.Value, 
Vessel_of_Interest = ALERT.<VESSEL>.Value 
GridView4.DataBind() 

GridViewG.DataSource = From ALERT Tn alertListl...<ALERT> Where 
ALERT.<ALERT_TO>.Value = "San Diego" And 
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(ALERT.<VESSEL>.<ORIGINATING_PORT>.Value = "San Diego" Or 
ALERT.<VESSEL>.<DESTINATION_PORT>.Value = "San Diego") Select Alert_To 
= ALERT.<ALERT_TO>.Value^ Suspense = ALERT.<SUSPENSE>.Value^ Comments = 
ALERT.<COMMENTS>.Value, Vessel_of_Interest = (ALERT.<VESSEL>.Value) 
GridViewG.DataBind() 

''Demonstrates traversing XML in a LINQ query. 

'For Each x In xmlDocument...<VESSELS>.<NAME> 

End Sub 

Public Sub LoadXMLDocument() 

xmlDocument = XDocument.Load(MapPath( "vessels.xml" )) 

End Sub 

' ' ' <summary> 

''' Query the vessels descendants for details using Element. 

''' </summary> 

''' <returns>Object</returns> 

Public Function DescendantsQueryl() As Object 

Return From VESSEL In xmlDocument...<VESSEL> Select Name = 
VESSEL.<NAME>.Value, MMSI - VESSEL.<MMSI>.Value, Est_Arrival - 
VESSEL.<EST_ARRIVAL>.Value, Originating_Port = 

VESSEL.<ORIGINATING_PORT>.Value, Destination_Port = 

VESSEL.<DESTINATION_PORT>.Value 

End Function 

''' <summary> 

''' Query the vessels descendants for details using Element. 

''' </summary> 

''' <returns>Object</returns> 

Public Function DescendantsQueryS() As Object 

Return From VESSEL In xmlDocument...<VESSEL> Where 
VESSEL.<DESTINATION_PORT>.Value = "San Diego" And 
VESSEL.<CLASSIFICATION>.Value = "Unclassified" Select Name = 

VESSEL.<NAME>.Value, MMSI = VESSEL.<MMSI>.Value, Est_Arrival = 

VESSEL.<EST_ARRIVAL>.Value, Originating_Port = 

VESSEL.<ORIGINATING_PORT>.Value, Destination_Port = 

VESSEL.<DESTINATION_PORT>.Value 

End Function 
End Class 

Listing 7. Language Integrated Query Sample Code 


The results produced from this framework are identical to those produced using 
XPath as the query language and were already shown (Figure 22 and Figure 23). Based 
on the integration of the query system with the existing vessel data sets, we can begin to 
develop rules for our ID to support the re-architecting of the system and the specification 
of our security policy using RuleML. 
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VI. THE INFORMATION DECLASSIFIER 


In support of the re-architecting effort based on the UML Use-Case analysis, we 
have added the concept of an Information Declassifier. The original process flow of 
Radiant Alloy relied on queries to the IB for direct results from associated repositories as 
shown in Figure 24. 



The revised process flow resulting from the rearchitecting process now includes 
the ID as an element of the architecture is shown in Figure 25. The ID is specified using 
RuleML and was required to satisfy the security use-case that was depicted in Figure 18 
and Figure 20. 
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The high-level operational vision for the ID and IB interaction can be explained 
as follows. The IB is the mechanism for user entry to the system and executing queries. 
The IB is also responsible for initiating the ID service and passing both user attributes 
and query data to the ID. The ID, which is replicated at all security domains in the MLS 
system, then begins its rule processing. The logical flow of IB and ID interaction is 
shown in Figure 26. 
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Figure 26. Flow Chart of the Operational Vision 


The parallelograms represent input or messaging, the reetangles represent 
processing, the diamonds represent decisions, and the circles are on-page continuations of 
flow. This flow chart does not show the iterative ID process that must occur for every IB 
query. The ID is also responsible for initiating the higher level ID services and passing 
the same parameters to the higher level ID (until the top domain is reached). Beyond this 
operational vision we must rely on the individual rule set to determine our policy and 
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implement its functionality. The entire rule set to support the Use Case of our analysis 
comprises approximately forty separate rules that use forward chaining, thereby allowing 
higher level rules to link to subordinate rules or variables to link fields in authorized 
queries to the system, as well as data classification and user security levels to form the 
basis for our evaluative process. 

Additionally, we have re-routed queries from the existing architecture to account 
for the presence of the ID and its role in the system. The Information Declassifier must 
act as an enforcer for information flows that may produce unwanted leakage. This 
leakage could be from disparate domains, or even within a domain but between Roles and 
to which a particular subject is not authorized the information that they obtain. These 
rules that we will describe and enact will be generated in RuleML. They can be executed 
on any XML specified data or code and are based on our High-Level Alert Use-Case 
scenario. Three cases must be addressed by the RuleML and Information Declassifier for 
the re-architecting: 

1. Reroute all User-IB queries and Inter-IB queries-queries must be routed to 
the ID and passed to the highest level ID/IB to allow for the inclusion of 
data from alert messages that are no longer visible at the requestor’s 
classification level. This includes both intra-domain and inter-domain 
interaction. 

2. Reroute all Alert Notification Messaging-Alerts must be routed through 
the system (we cannot control out-of-band), but we must provide for a 
distribution method within the system through the ID. 

3. Reroute all Repository Responses-Data responses must be routed through 
the IB / ID pair, to verify appropriately for action against the rule engine. 
This will help in efforts of need to share and need not to share while 
providing support to allow for information filtering. 

The Information Broker implementation must be extended to contain an 
orchestration mechanism to invoke the ID. Similar to the rules for a security kernel, we 
must ensure that the orchestration mechanism in the IB service is always invoked and 
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tamperproof. Whenever a request or query reaches the IB service, the orchestration will 
invoke the ID and pass the same informational query, along with the user credentials and 
role details in the messaging. The IB will continue to execute its primary objective in 
gathering data from the associated data repositories, but it will also wait for a response 
from the ID service that was invoked. There will be two cases of response from the ID. A 
negative response from the ID will result in the IB returning whatever data it found 
initially, with respect to the role-mapped permissions for the user. A positive response 
from the ID will cause the IB to augment its results with the additional information that 
the ID returned. 

A means to mitigate risk is to create and derive the rule base that will be used by 
the ID. Depending upon the most critical information sharing concerns and the need to 
prevent specified misuse, we will create a rule base that will isolate and address those 
areas. This will never be all inclusive, nor will each of the cases be mutually exclusive. 
Certain information sharing rules will overtly conflict with others and will have to be 
reconciled to achieve an acceptable result for information flow. This ambiguity must be 
reconciled in the development of the overall security policy. This support of the re¬ 
architecting effort based on the UML Use-Case will help to ensure that we maintain our 
security property for the emergent behaviors that are most critical within our information 
system, based on the expressed operational context used in this research. 

A. RULES FOR THE INFORMATION DECLASSIFIER 

RuleML’s expressive power offers the potential to implement a rule engine for an 
ID that is robust enough to function in an MLS environment, yet still flexible enough to 
allow for intricate rule usage. The rules generated for a RuleML-based ID must be 
reactionary; much like the rules for an Access Control List (ACL) on a router. The base 
set of rules is reactionary and, once the requisite functionality is enabled, can be 
augmented with derivation and transformational rules. These rules can be replicated 
between domains and changed readily, yet they still have sufficient expressive power to 
specify the AIS security policy. 
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Precise translation from an English language security policy to a specification for 
that same policy expressed with RuleML is difficult. In support of the re-architecting, and 
in order to ensure the soundness and completeness of our ID implementation using 
RuleML, two main categories were addressed to meet our security use case. Intra-domain 
rules were necessary to provide for filtering of information within a domain, while inter¬ 
domain queries allow for the injection of data necessary when Alert Messages are present 
in the system and data must be added to avoid the loss of safety. RuleML allows for 
predicates and rules to be sourced either internally (within a service) or externally (a call 
to a separate service). In the case of our ID, we highlighted the Reaction RuleML side to 
produce a positive response from our ruleset. The entire developed ruleset consists of 
forty-one rules which will be covered in detail. Some of these rules were created to 
replicate other services and responses within our envisioned system that were both 
beyond the scope and could not easily be replicated for this research. The RuleML set can 
be expressed in Backus-Naur form (BNF) and the trace through the ruleset can be 
completed as though the entire ruleset were a context-free grammar (CFG). 

The predicates used for the creation of the ruleset are shown in Listing 8. These 
mappings indicate possible values utilized for the MDA scenario and the header code is 
included in Listing 9. 
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Alert_Present_Response “True” I “False” (Currently User defined - would be IB 
service response) 

Classification_Level “Unclassified” I “Secret” I “Top Secret” 
Data_Classification_Level “Unclassified” I “Secret” I “Top Secret” 
EWO_Valid_Query User_Role && User_Security_level && PDP_Decision 
HM_Queries “Originating Port” I “Destination Port” 

HM_Valid_Query Oakland Harbormaster query is valid destination I Oakland 
Harbormaster query is valid origination I SD Harbormaster query is valid destination 
I SD Harbormaster query is valid origination 
IB_Classification_Level “Unclassified” I “Secret” I “Top Secret” 

IB_Response_Wait Valid_Query && Query_Requires_Data_Insertion 
PDP_Decision -> User_Role_Permissions 
Query_Requires_Data_Insertion Alert_Present_Response 

Return_IB_Results “Vessel Results from Unclassified IB” I “Vessel Results from 
Unclassified IB with ID Injection” I “Vessel Results from Secret IB and Unclassified 
IB” I “Vessel Results from Secret IB and Unclassified IB with ID Injection” I 
“Vessel Results from Top Secret IB and Secret IB and Unclassified IB” 
Security_Level -> “Unclassified” I “Secret” I “Top Secret” 

User_Role -> “EWO” I “Electronic Warfare Officer” I “Harbormaster” I “Harbormaster 
San Diego” I “Harbormaster Oakland” I “Harbormaster Shanghai” 
User_Role_Location “San Diego” I “Oakland” I “Shanghai” I “Not Reported” 
User_Role_Permissions “True” I “False” (Currently User defined - would be PDP 
service response) 

User_Security_Level “Unclassified” I “Secret” I “Top Secret” 

Valid_Query HM_Valid_Query I EWO_Valid_Query 

Vessel_Classification_Level User_Role && User_Security_level && PDP_Decision 
Vessel_Destination_Port User_Role_Location 
Vessel_Originating_Port User_Role_Location 
Listing 8. RuleML Predicate Listing 

The rules created for this scenario were numbered using RulelDs from zero to forty 
and encoded after creating a natural language description for the rule. Header data is 
established to begin the RuleML coding. This includes creating the rule base and 
establishing the location and naming for rules with the uniform resource identifier (URI). 
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<?xml version="l . 0" encoding="ut f-8" ?> 

<RuleML xmlns="http ://www.ruleml.org/0. 91/xsd"> 
<Rulebase> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>MDA_Scenario_Arvay_current</ Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>12/4/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<!— Rule Policy Information_Declassifier —> 

<!— oid of the rule base / module —> 

<Ind>Inf ormation_Declass!fie r</ Ind> 


Listing 9. RuleML Header Code for Information Declassifier 


The rules are constructed to produce a confirmed result, positive or negative, for 
every query. No implicit deny rule was established for this proof-of-concept ruleset. Each 
of the rules is detailed in Appendix A and contains summary information for the intent of 
the rule as well as the actual RuleML code that enacts the rule within the system. 

The intended functionality of the information declassifier consists of several parts 
and rules were written to fulfill those component functions as shown in Figure 27 and the 
summary of the rule naming is shown in Listing 10. 
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Figure 27. Functional Support for Ruleset 


RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 


0: Alert Not Valid for Role Location. 

1: Alert Notification is Present. 

2: Est Location for Role. 

3: IB Results 0. 

4: Oakland Harbormaster query is valid destination. 
5: PDF Decision. 

6 : Positive ID Response to IB for Alert. 

7: Query is Valid. 

8: Alert Notification is Absent. 

9: Alert SD Secret IB. 

10: EWO Query is Valid. 

11: IB Results 2. 

12: Negative ID Response to IB for Alert. 
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RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 

RulelD 


13: Oakland Harbormaster query is valid destination 2. 
14: POP Decision 2. 

15: Query is Invalid. 

16: Alert SD Secret IB 2. 

17: IB Results 3. 

18: Oakland Harbormaster query is valid origination. 
19: Alert SDTS IB. 

20: EWO Query is Valid 2. 

21: IB Results 4. 

22: Oakland Harbormaster query is valid origination 2. 
23: Alert SDTS IB. 

24: IB Results 5. 

25: SD Harbormaster query is valid destination. 

26: Alert Oak Secret IB. 

21: IB Results 6. 

28: SD Harbormaster query is valid destination 2. 

29: Alert Oak Secret IB 2. 

30: SD Harbormaster query is valid origination. 

31: Alert Oak TS IB. 

32: SD Harbormaster query is valid origination 2. 

33: Alert Oak TS IB 2. 

34: IB Results 0.1. 

35: IB Results 0.2. 

36: IB Results 0.3. 

37: No Alert IB. 

38: IB Results 2.1. 

39: EWO Query is Invalid. 

40: HM Query is Invalid. 


Listing 10. RuleML Rule Names 
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As this proof of concept was not applied to a production system, many conditional 
rules were required to establish the user credentials and origination data of system 
queries. These are support rules to allow the validation checks and path determination for 
the Information Deelassifier to operate. With a live production system the use of a Global 
Content Delivery System (GCDS), or even Microsoft Active Directory in a deprecated 
case would suffice to provide this level of background and statistical data. Additionally, 
the cheeks on alert deeisioning were not based on a live repository, so the rules 9, 16, 19, 
23, 26, 29, 31, and 33 were all created to replicate this funetionality depending on the 
variable set established in the originating query and sample case. With a live repository 
and a web application tied into an Oracle (or other) database, these rules would be 
replaeed with a real-time response from that instanee. Eaeh of these rules eombine to 
form the basis for expressing our information broker’s interaction with a declassifier 
using RuleML, and demonstrate the interaction required with using a rule engine to 
exercise these rules. 

1. Intra-Domain (Filtering) 

By establishing rules that can be enforced within a single information domain, we 
can effectively limit the ability of users to obtain information to which they are not 
authorized. One aspect of this intra-domain restriction can be represented by our desire to 
restriet a Harbormaster’s queries to those ports whieh directly apply to his Role loeation. 
Aeeordingly, if the San Diego Harbormaster wants to query the system for data, then we 
should only give him the data necessary for the execution of his role. In practice, we want 
the ID to have a rule that represents the idea that “the Harbormaster’s query must only 
obtain data whieh ineludes his Role’s port (i.e., San Diego) as either the Origination_Port 
or the Destination_Port.’’ 

2. Inter-Domain (Injection) 

The ID must aet as an intermediary between varying security domains, 
represented by an IB at eaeh domain level. This is neeessary to process queries from 
lower classification levels and to pull data pertaining to Alert Message Notifications from 
higher classification level data stores. When a higher classification or different domain 

109 



level user touches the data pertaining to a VOI, the lower level user can no longer view 
that data. This may be counter to their role and responsibilities where they are, in fact, 
entitled and required to access this information. This information could also be critical to 
their performance of duties while fulfilling an established Role in the system. The ID 
would first receive a query message from a domain level IB. This IB is attempting to 
provide a user with requested data, but in order to prevent an information flow problem 
as described in our Use-Case scenario, must ask the higher level IB for Alert Message 
information. This request to a different domain IB, must be processed through a trusted 
entity, in this case the Information Declassifier that resides between the respective IB 
domains. As an IB receives a lower level IB query, it must first send a similar request to 
its higher level (thru the ID between its domains), then it must query its own Alert 
Message Notification stores for data. Pending the results of the higher level answer and 
its own Alert Message result, it will generate a Negative Response for No Data Found, or 
a Positive Response with the associated dataset. The Positive Response will be 
aggregated to the lower level’s own query results, while the Negative Response will 
result in the IB (at whatever level) processing the query and returning any result it finds 
(based on user permissions for the Role). 

3. Individual Ruleset Descriptions and Purpose 

RulelD 0 is titled Alert Not Valid for Role Location. This rule is intended to 
eliminate possibilities for Alert Messaging responses that are not valid for our scenario. If 
an Alert exists for Los Angeles in the system (at a higher level IB), then this rule toggless 
that notification to FALSE, since it does not apply to the port of San Diego. 

RulelD 1 is titled Alert Notification is Present. This rule is intended to set the 
variable Query_Requires_Data_Insertion to TRUE, if the higher level IB possesses an 
Alert Message. In this ruleset, the external reference is not made, but invoked through the 
use of an internally generated variable for the sourcing. 

RulelD 2 is titled Est Location for Role. This rule is intended to fix the 
assignment of the user’s role location to the results being returned from the IB. This will 
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allow for additional filtering to match the user’s location with vessel results from the data 
repositories that match with origination or destination ports. 

RulelD 3 is titled IB Results 0. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Unclassified IB with 
ID Injection for Oakland Alert.” This is done after checking the user’s security level and 
for the presence of an alert for this location. This rule was created to allow for 
Harbormaster queries from the port of Oakland as an extension to the San Diego port 
accounted for in our scenario. 

RulelD 4 is titled Oakland Harbormaster query is valid destination. This is one of 
the rules used as an extension to our primary scenario, which would allow for the port of 
Oakland queries to also work in the system. It is used to verify the user role, the role 
location, the PDF decision, and the type of query before deciding that it is a valid query 
and should be processed by the IB. 

RulelD 5 is titled PDF Decision. This is an externally sourced rule that would be 
completed by the Policy Decision Point service in our SOA system. It is used, based on the 
variables it is sourced with, to provide a decision for that user’s access to resources in the 
system. In this implementation, it is not referenced from an actual external PDP service. 

RulelD 6 is titled Positive ID Response to IB for Alert. This rule is used to 
indicate a positive response to the presence of an Alert Message at a higher level IB and 
verifies that the query to the IB is valid based on the roles active in our system. This rule 
ensures that the IB response that was previously returned directly to the user is now 
processed through the ID and missing data is injected to the query if necessary, to 
eliminate the Misuse Case and as a <Prevent> feature of our Security Use Case. This rule 
is designed to verify other rules that determine if the query to the system is valid, and if 
the response from the higher level IB requires the system to inject data before processing 
the query response. It also checks if the query requires data insertion, which is sourced 
from the higher level IBs. If both of these conditions are TRUE, then the IB that received 
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the query is informed that its response to the user must wait for the injection messaging 
from the ID service prior to returning results to the user. 

RulelD 7 is titled Query is Valid. This is a filtering rule and is used to verify that the 
user (EWO or Harbormaster) is requesting an allowable query. It is sourced from two other 
rules, which check the validity of the query against each actor’s allowable query set. 

RulelD 8 is titled Alert Notification is Absent. This rule is intended to set the 
variable Query_Requires_Data_Insertion to FALSE, if the higher level IB does not 
possess an Alert Message. In this ruleset, the external reference is not made, but invoked 
through the use of an internally generated variable for the sourcing. 

RulelD 9 is titled Alert SD Secret IB. This rule is used to verify that when an alert 
is present at the Secret level IB, intended for San Diego, and the requestor is at the 
Unclassified security level, that the Alert_Present_Response is set to TRUE. This will 
indicate to the ID and IB that an alert is present that pertains to the user query, and that 
the user is below the alert’s classification level. 

RulelD 10 is titled EWO Query is Valid. This is a filtering rule and is used to 
verify that the user fulfilling the EWO role is requesting an allowable query. It is checked 
against the actor’s allowable query set, to determine validity. 

RulelD 11 is titled IB Results 2. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Secret IB and 
Unclassified IB with ID Injection for Oakland Alert.’’ This is done after checking the 
user’s security level and for the presence of an alert for this location. The IB, in this case, 
would return its regular result from both the Unclassified and Secret level IB (since the 
user is at the Secret level), and then the required Alert Message insertion from the TS IB. 
This rule was created to allow for Harbormaster queries from the port of Oakland as an 
extension to the San Diego port accounted for in our scenario. 

RulelD 12 is titled Negative ID Response to IB for Alert. This rule provides an 
acknowledgment of a negative result for the presence of an alert message. This is used to 
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trigger other rules in the ruleset and to ensure that the ID returns a result in all cases. 
Without this rule, it is possible for the ID to return nothing, which allows for ambiguity in 
the ruleset. The rule checks if the query requires data insertion, which is sourced from the 
higher level IBs. If FALSE, then the IB that received the query is informed that its 
response to the user does not need to wait for the ID injection messaging prior to 
returning results to the user. 

RulelD 13 is titled Oakland Harbormaster query is valid destination 2. This rule 
is almost a duplicate of RulelD 4, but is used to support an alternative method of 
designating roles. In this case, if the role is listed as Harbormaster Oakland, instead of the 
generic Harbormaster designation, then the rule will process similarly. This is one of the 
rules used as an extension to our primary scenario, which would allow for the port of 
Oakland queries to also work in the system. It is used to verify the user role, the role 
location, the PDF decision, and the type of query before deciding that it is a valid query 
and should be processed by the IB. 

RulelD 14 is titled PDF Decision 2. This is an externally sourced rule that would 
be completed by the Policy Decision Point service in our SOA system. It is used, based 
on the variables it is sourced with, to provide a decision for that user’s access to resources 
in the system. In this implementation, it is not referenced from an actual external PDF 
service, and this rule is intended to provide a positive response to the service check for a 
negative response. 

RulelD 15 is titled Query is Invalid. This is a filtering rule and is used to verify 
that the user (EWO or Harbormaster) is requesting an allowable query. It is sourced from 
two other rules, which check the validity of the query against each actor’s allowable 
query set. This rule is intended to provide a positive response to the query check in the 
case of a negative response. 

RulelD 16 is titled Alert SD Secret IB 2. This rule is used to verify that when an 
alert is present at the Secret level IB, intended for San Diego, and the requestor is at the 
Unclassified security level, that the Alert_Present_Response is set to TRUE. This will 
indicate to the ID and IB that an alert is present that pertains to the user query, and that 
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the user is below the alert’s classification level. This rule is equivalent to RulelD 9 and is 
used to support an alternative method of designating roles. In this case, if the role is listed 
as the generic Harbormaster, instead of the Harbormaster San Diego designation, then the 
rule will process similarly. 

RulelD 17 is titled IB Results 3. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Secret IB and 
Unclassified IB.” This is done after checking the user’s security level and for the 
presence of an alert for this location. The IB, in this case, will return its regular result 
from both the Unclassified and Secret level IB (since the user is at the Secret level). 

RulelD 18 is titled Oakland Harbormaster query is valid origination. This rule is 
supports an alternative method of designating roles. In this case, if the role is listed as 
Harbormaster Oakland, instead of the generic Harbormaster designation, then the rule 
will process similarly. This is one of the rules used as an extension to our primary 
scenario, which would allow for the port of Oakland queries to also work in the system. It 
is used to verify the user role, the role location, the PDF decision, and that the query type 
is for an Originating Port before deciding that it is a valid query and should be processed 
by the IB. 

RulelD 19 is titled Alert SD TS IB. This rule serves as a trigger within the ruleset 
to identify that an Alert Message is present and to verify the level of the Alert Message 
against the security level of the user producing the query. This rule is used to verify that 
when an alert is present at the Top Secret level IB, intended for San Diego, the requestor 
is at the Unclassified or Secret security level, and that the Alert_Present_Response is set 
to TRUE. This will indicate to the ID and IB that an alert is present that pertains to the 
user query, and that the user is below the alert’s classification level. 

RulelD 20 is titled EWO Query is Valid 2. This is a filtering rule and is used to 
verify that the user fulfilling the EWO role is requesting an allowable query. It is checked 
for validity against the actor’s allowable query set. This rule is equivalent to RulelD 10, 
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but accounts for a different role naming convention. In this case, the user’s role is 
Electronic Warfare Officer, instead of EWO. 

RulelD 21 is titled IB Results 4. This is one of the ten IB results rules that is 
intended to replieate the results from an aetual IB. It is used, based on the variables it is 
soureed with, to provide an expeeted result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Unclassified IB.” This 
is done after checking the user’s security level and for the presence of an alert for this 
location being FALSE. The IB, in this case, would return its regular result from the 
Unelassified-level IB. 

RulelD 22 is titled Oakland Harbormaster query is valid origination 2. This rule 
is almost a duplieate of RulelD 18, but is used to support an alternative method of 
designating roles. In this case, if the role is listed as the generie Harbormaster, instead of 
the Harbormaster Oakland designation, then the rule will process similarly. This is one of 
the rules used as extension to our primary scenario, which would allow for the port of 
Oakland queries to also work in the system. It is used to verify the user role, the role 
location, the PDF deeision, and the type of query is an originating port query before 
deciding whether it is a valid query and should be processed by the IB. 

RulelD 23 is titled Alert SD TS IB. This rule is used to verify that when an alert is 
present at the Top Secret level IB, intended for San Diego, and the requestor is at the 
Unelassified or Seeret seeurity level, that the Alert_Present_Response is set to TRUE. 
This will indieate to the ID and IB that an alert is present that pertains to the user query, 
and that the user is below the alert’s classification level. This rule is equivalent to RulelD 
19 and is used to support an alternative method of designating roles. In this case, if the 
role is listed as the generic Harbormaster, instead of the Harbormaster San Diego 
designation, then the rule will proeess similarly. 

RulelD 24 is titled IB Results 5. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from TS IB, Seeret IB and 
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Unclassified IB.” This is done after checking the user’s security level is equal to Top 
Secret. The user in this case is authorized all data from each of the classification levels 
and does not require injection to the IB results. 

RulelD 25 is titled SD Harbormaster query is valid destination. This rule is used 
to verify the user role as Harbormaster, the role location is San Diego, the PDF decision 
is TRUE, and the query is both valid and of the type Destination_Port_Query before 
deciding whether it is valid and should be processed by the IB. 

RulelD 26 is titled Alert Oak Secret IB. This rule is established as a trigger within 
the ruleset to identify that an Alert Message is present and to verify the level of the Alert 
Message against the security level of the user producing the query. This particular rule is 
used as an extension to our baseline scenario to account for users at the port of Oakland. 
This will indicate to the ID and IB that an alert is present that pertains to the user query, 
and that the user is below the alert’s classification level. 

RulelD 27 is titled IB Results 6. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with to provide an expected result when testing the rulebase with a sample query. 
In this case, it returns the IB result of “Invalid Query!” This is done after checking the 
query validity from the ValidjQuery variable. 

RulelD 28 is titled SD Harbormaster query is valid destination 2. This rule is 
identical in functionality to RulelD 25, but supports the extended role convention using 
Harbormaster San Diego instead of the generic Harbormaster role. This rule is used to 
verify the user role as Harbormaster San Diego, the PDF decision is TRUE, and the type 
of query is Destination_Port_Query before deciding that it is valid and should be 
processed by the IB. 

RulelD 29 is titled Alert Oak Secret IB 2. This rule is established as a trigger 
within the ruleset to identify that an Alert Message is present and to verify the level of the 
Alert Message against the security level of the user producing the query. It is identical in 
functionality to RulelD 26, but supports the generic role moniker of Harbormaster 
instead of Harbormaster Oakland. This particular rule is used as an extension to our 
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baseline scenario to account for users at the port of Oakland. This will indicate to the ID 
and IB that an alert is present that pertains to the user query, and that the user is below the 
alert’s classification level. 

RulelD 30 is titled SD Harbormaster query is valid origination. This rule is 
identical in functionality to RulelD 32, but supports the extended role convention using 
Harbormaster San Diego instead of the generic Harbormaster role. This rule is used to 
verify the user role as Harbormaster San Diego, the PDF decision is TRUE, and the type 
of query is Originating_Port_Query before deciding that it is valid and should be 
processed by the IB. This rule checks the query that is being processed and sets 
conditions to restrict the IB response as a result. This rule is designed to eliminate the 
user’s ability to repeatedly query the system to troll for information, or the lack of 
information, again a key element in preventing the Misuse Case. In the original system, 
queries were directly processed by the IB after entry. In the re-architected system, we 
reroute all queries through the ID (per Figure 26) where we begin the new data flow at 
continuation point I instead of direct processing by the IB in the original flow. In this 
case, the query and resultant data must include the Harbormaster’s port (either 
Origination or Destination) for details to be returned by the IB and ID. This is part of the 
<Detect> in the Security Use Case that we had to reroute queries in the system. This will 
prevent a Harbormaster from continually querying the system to get information about 
vessels from the system that do not directly pertain to his or her role (at his location) and 
his normal performance of duty. This rule verifies that the user is a Harbormaster from 
San Diego and conducting an Originating Port Query, which he is authorized because of 
his role’s duties and obligations, as well as a PDP service check to validate the role’s 
permissions to execute a basic query and to access information from the IB. The rule then 
establishes this as a valid query for the San Diego Harbormaster, while it also restricts the 
query response by limiting Vessel_Classification_Level to the User_Security_Level, and 
setting the field for Vessel_Originating_Port to the User_Role_Location, or in this case 
San Diego. 

RulelD 31 is titled Alert Oak TS IB. This rule is established as a trigger within the 
ruleset to identify that an Alert Message is present and to verify the level of the Alert 
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Message against the security level of the user producing the query. It is identical in 
functionality to RulelD 33, but supports the generic role moniker of Harbormaster 
instead of Harbormaster Oakland. This particular rule is used as an extension to our 
baseline scenario to account for users at the port of Oakland. This will indicate to the ID 
and IB that an alert is present that pertains to the user query, and that the user is below the 
alert’s classification level. 

RulelD 32 is titled SD Harbormaster query is valid origination 2. This rule is 
almost a duplicate of RulelD 30, but is used to support an alternative method of 
designating roles. In this case, if the role is listed as the generic Harbormaster, instead of 
the Harbormaster San Diego designation, then the rule will process similarly. This rule 
checks the query that is being processed and sets conditions to restrict the IB response as 
a result. This rule is designed to eliminate the user’s ability to repeatedly query the 
system to troll for information, or the lack of information, serving as a key element in 
preventing the Misuse Case. In the original system, queries were directly processed by 
the IB after entry. In the re-architected system, we reroute all queries through the ID (per 
Figure 26) where we begin the new data flow at continuation point I instead of direct 
processing by the IB in the original flow. In this case, the query and resultant data must 
include the Harbormaster’s port (either Origination or Destination) for details to be 
returned by the IB and ID. This is part of the <Detect> in the Security Use Case that we 
had to reroute queries in the system. This will prevent a Harbormaster from continually 
querying the system to get information about vessels from the system that do not directly 
pertain to his or her role (at this location) and their normal performance of duty. This rule 
verifies that the user is a Harbormaster from San Diego and conducting an Originating 
Port Query, which he is authorized because of his role’s duties and obligations, as well as 
a PDP service check to validate the role’s permissions to execute a basic query and to 
access information from the IB. The rule then establishes this as a valid query for the San 
Diego Harbormaster, while it also restricts the query response by limiting 
Vessel_Classification_Level to the User_Security_Level, and setting the field for 
Vessel_Originating_Port to the User_Role_Location, or in this case San Diego. 


118 



RulelD 33 is titled Alert Oak TS IB 2. This rule is established as a trigger within 
the ruleset to identify that an Alert Message is present and to verify the level of the Alert 
Message against the seeurity level of the user producing the query. This rule is identical 
in functionality to RulelD 30. This particular rule is used as an extension to our baseline 
scenario to account for users at the port of Oakland. This will indicate to the ID and IB 
that an alert is present that pertains to the user query, and that the user is below the alert’s 
classification level. 

RulelD 34 is titled IB Results 0.1. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Unclassified IB with 
ID Injection for Oakland Alert.” This is done after checking the user’s security level and 
for the presence of an alert for this location. The IB, in this case, would return its regular 
result from the Unclassified level IB (since the user is at the Unclassified level), and then 
the required Alert Message insertion from the higher (TS or Secret) IB. The level of the 
Alert Message is not revealed to the user from the IB. This rule was created to allow for 
Harbormaster queries from the port of Oakland as an extension to the San Diego port 
accounted for in our scenario. 

RulelD 35 is titled IB Results 0.2. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with, to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Unclassified IB with 
ID Injection for San Diego Alert.” This is done after checking the user’s security level 
and for the presence of an alert for this location. The IB, in this case, would return its 
regular result from the Unclassified level IB (since the user is at the Unclassified level), 
and then the required Alert Message insertion from the higher (TS or Secret) IB. The 
level of the Alert Message is not revealed to the user from the IB. 

RulelD 36 is titled IB Results 0.3. This is one of the ten IB results rules that is 

intended to replicate the results from an actual IB. It is used, based on the variables it is 

sourced with, to provide an expected result when testing the rule base with a sample 
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query. In this case, it returns the IB result of “Vessel Results from Unclassified IB with 
ID Injection for San Diego Alert.” This is done after checking the user’s security level 
and for the presence of an alert for this location. The IB, in this case, would return its 
regular result from the Unclassified level IB (since the user is at the Unclassified level), 
and then the required Alert Message insertion from the TS IB. The level of the Alert 
Message is not revealed to the user from the IB. 

RulelD 37 is titled No Alert IB. This rule serves as a trigger within the ruleset to 
identify that an Alert Message is not present at a higher level IB. This indicates a 
negative search result from within the IB (i.e., no alert message found). 

RulelD 38 is titled IB Results 2.1. This is one of the ten IB results rules that is 
intended to replicate the results from an actual IB. It is used, based on the variables it is 
sourced with, to provide an expected result when testing the rule base with a sample 
query. In this case, it returns the IB result of “Vessel Results from Secret IB and 
Unclassified IB with ID Injection for San Diego Alert.” This is done after checking the 
user’s security level and for the presence of an alert for this location. The IB, in this case, 
would return its regular result from both the Unclassified and Secret level IB (since the 
user is at the Secret level), and then the required Alert Message insertion from the TS IB. 

RulelD 39 is titled EWO Query is Invalid. This is a filtering rule and is used to 
verify that the user (EWO) is requesting an allowable query. It verifies the role of the 
query requestor and is intended to provide a positive response to the query check in the 
case of a negative response (i.e., an invalid query request). 

RulelD 40 is titled HM Query is Invalid. This is a filtering rule and is used to 
verify that the user (Harbormaster) is requesting an allowable query. In this case, it 
allows for Harbormaster queries to originate from San Diego and Oakland only. Any 
other location for the role of a Harbormaster will make the query invalid. It verifies the 
role of the query requestor and is intended to provide a positive response to the query 
check in the case of a negative response (i.e., an invalid query request). 
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B. REGRESSION TESTING 


Several rule engines exist for integration and use with RuleML. For this research 
we initially selected VDR-Device [68] as a visual integrated development environment 
and additionally, we used Acumen Business’s The Rule Manager [69] to assist with 
visual rule mapping and stepping through the proof cases for our ruleset with its ability to 
allow interaction and establish parameter values as the rule trace progresses. As a part of 
regression testing as each new rule was implemented or changed a full testing process of 
all rules was conducted again. Three main cases exist for our ruleset to provide a clear 
and convincing argument that it is sound and complete. The first case is to demonstrate 
that all intended functionality and usage that was provided for in the original system is 
still available. This is despite the fact that we are now going through an additional service 
and utilizing a RuleML ruleset to specify our security policy. The second case is to 
demonstrate that the unintended use (and the loss of safety) of the system that was 
described from the misuse case is now prevented. The third and final piece is to show that 
unintended or ancillary queries are not answered by our system inadvertently. This shows 
that no additional use is allowed by the implementation of our ruleset than that which was 
present in the original system. 

1. Intended Use Is Maintained 

The original functionality is maintained by the system, despite the incorporation 

of our re-architecting and the implementation of the ID and its ruleset. To show that this 

still works as it did prior to this, we will process a query using the following parameters: 

Type of query: Destination Port 

Role / Actor: Harbormaster 

Location: San Diego 

Security Level: Unclassified 

Alert Present: False 

Alert Classification Level: Not Applicable 

Expected Result: “Vessel Results from Unclassified IB” 
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The expected result from this query and the RuleML execution is an IB response 
of “Vessel Results from Unclassified IB” to the user. The trace of this query execution 
through the ruleset can be seen in Appendix B, which depicts the query and ruleset using 
RuleManager’s Interactive Rule Map functionality. In Appendix B, the detailed view of 
the trace also shows the individual variables and terms from within each rule being 
sourced as the engine completes its evaluation. These terms are referenced by the 
individual rule and then evaluated to determine the end result for each rule. For this 
query, Return_IB_Results is the main variable (and expressed at the root of the rule tree) 
that is sourced from the ten different IB Result rules. Those rules were designed to 
replicate the external services that were not implemented for this research. Each IB 
Result rule can begin the trace to evaluate down to the base predicates (terminals in a 
CFG) that are necessary to resolve or decide the rule. This may be iterative in stepping 
through other rules to source the necessary values for the rule in question. In the first 
query instance, the IB Results 2.1 rule (RulelD 38) is the rule chosen to begin the 
sourcing of Return_IB_Results. The trace is as follows: 


1. RulelD 38-IB Results 2.1 

2. RulelD 40-HM Query is Invalid 

3. RulelD 32-SD Harbormaster query is valid origination 2 

4. RulelD 30-SD Harbormaster query is valid origination 

5. RulelD 14-Policy Decision Point 2 

6. RulelD 5-Policy Decision Point 

7. RulelD 28-SD Harbormaster query is valid destination 2 

8. RulelD 25-SD Harbormaster query is valid destination 

9. RulelD 22-Oakland Harbormaster query is valid origination 2 

10. RulelD 18-Oakland Harbormaster query is valid origination 

11. RulelD 13-Oakland Harbormaster query is valid destination 2 


Sourced 

Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Fired 
Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
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Did Not Fire 


12. RulelD 4-Oakland Harbormaster query is valid destination 

13. RulelD 39-EWO query is invalid 

14. RulelD 20-EWO query is valid 2 

15. RulelD lO-EWO query is valid 

16. RulelD 15-Query Invalid 

17. RulelD 7-Query is Valid 

18. RulelD 37-No Alert IB 

19. RulelD 33-Alert Oak TS IB 2 

20. RulelD 31-Alert Oak TS IB 

21. RulelD 29-Alert Oak Secret IB 2 

22. RulelD 26-Alert Oak Secret IB 

23. RulelD 23-Alert SD TS IB 2 

24. RulelD 19-Alert SD TS IB 

25. RulelD 16-Alert SD Secret IB 2 

26. RulelD 9-Alert SD Secret IB 

27. RulelD 0-Alert Not Valid for Role Location 

28. RulelD 8-Alert Notification is Absent 

29. RulelD 1-Alert Notification is Present 

30. RulelD 12-Negative ID Response to IB for Alert 

31. RulelD 6-Positive ID Response to IB for Alert 

32. RulelD 38-IB Results 2.1 

33. RulelD 36-IB Results 0.3 

34. RulelD 35-IB Results 0.2 

35. RulelD 34-IB Results 0.1 


Eired 

Did Not Fire 
Did Not Fire 
Fired 
Fired 
Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Fired 
Fired 

Did Not Fire 
Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
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36. RulelD 27-IB Results 6 

Did Not Fire 

37. RulelD 24-IB Results 5 

Did Not Fire 

38. RulelD 21-IB Results 4 

Fired 

39. RulelD 17-IB Results 3 

Did Not Fire 

40. RulelD 11-IB Results 2 

Did Not Fire 

41. RulelD 3-IB Results 0 

Did Not Fire 


RulelDs 0^0 were each evaluated and either fired or did not fire. The originating rule 
(Step 1. IB Results 2.1) to begin the sourcing Did Not Fire in Step 32. Despite the ruleset 
finding its result after Step 38 when RulelD 21 Fired, the remaining rules are still 
evaluated in the ruleset for completeness. The RulelD 21 for IB Results 4 produced the 
expected result for this query of “Vessel Results from Unclassified IB.” This query 
effectively shows that the ruleset does not hinder the intended functionality or usage of 
the system. All original queries that were allowed are still supported with no change to 
the resultant data. 

2. Unintended Use Is Prevented 

The second case for our clear and convincing argument consists of our safety 

property violation for information flow. The misuse of the system must be prevented by 

our re-architecting and the implementation of the ID and its ruleset. To show that this 

misuse has been prevented we will process a query using the following parameters: 

Type of query: Destination Port 

Role / Actor: Harbormaster 

Location: San Diego 

Security Level: Unclassified 

Alert Present: True 

Alert Classification Level: Secret 

Expected Result: “Vessel Results from Unclassified IB with ID 

Injection for Port of San Diego” 


The expected result from this query and the RuleML execution is an IB response 
of “Vessel Results from Unclassified IB with ID Injection for Port of San Diego” to the 

user. The trace of this query execution through the ruleset can be seen in Appendix C, 
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which depicts the query and ruleset using RuleManager’s Interactive Rule Map 
functionality. In Appendix C, the detailed view of the trace also shows the individual 
variables and terms from within eaeh rule being sourced as the engine eompletes its 
evaluation. These terms are referenced by the individual rule and then evaluated to 
determine the end result for each rule. For this query, Return_IB_Results is the main 
variable (and expressed at the root of the rule tree) that is sourced from the ten different 
IB Result rules. Those rules were designed to replicate the external serviees that were not 
implemented for this research. Each IB Result rule ean begin the trace to evaluate down 
to the base predicates (terminals in a CFG) that are necessary to resolve or decide the 
rule. This may be iterative in stepping through other rules to source the necessary values 
for the rule in question. In the first query instanee, the IB Results 2.1 rule (RulelD 38) is 
the rule chosen to begin the sourcing of Return_IB_Results. The traee is as follows: 


1. RulelD 38-IB Results 2.1 

2. RulelD 40-HM Query is Invalid 

3. RulelD 32-SD Harbormaster query is valid origination 2 

4. RulelD 30-SD Harbormaster query is valid origination 

5. RulelD 14-Policy Decision Point 2 

6. RulelD 5-Policy Decision Point 

7. RulelD 28-SD Harbormaster query is valid destination 2 

8. RulelD 25-SD Harbormaster query is valid destination 

9. RulelD 22-Oakland Harbormaster query is valid origination 2 

10. RulelD 18-Oakland Harbormaster query is valid origination 

11. RulelD 13-Oakland Harbormaster query is valid destination 2 

12. RulelD 4-Oakland Harbormaster query is valid destination 

13. RulelD 39-EWO query is invalid 


Sourced 

Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Fired 
Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Fired 
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14. RulelD 20-EWO query is valid 2 

15. RulelD lO-EWO query is valid 

16. RulelD 15-Query Invalid 

17. RulelD 7-Query is Valid 

18. RulelD 37-No Alert IB 

19. RulelD 33-Alert Oak TS IB 2 

20. RulelD 31-Alert Oak TS IB 

21. RulelD 29-Alert Oak Secret IB 2 

22. RulelD 26-Alert Oak Secret IB 

23. RulelD 23-Alert SD TS IB 2 

24. RulelD 19-Alert SD TS IB 

25. RulelD 16-Alert SD Secret IB 2 

26. RulelD 9-Alert SD Secret IB 

27. RulelD 0-Alert Not Valid for Role Location 

28. RulelD 8-Alert Notification is Absent 

29. RulelD 1-Alert Notification is Present 

30. RulelD 12-Negative ID Response to IB for Alert 

31. RulelD 6-Positive ID Response to IB for Alert 

32. RulelD 38-IB Results 2.1 

33. RulelD 36-IB Results 0.3 

34. RulelD 35-IB Results 0.2 

35. RulelD 34-IB Results 0.1 

36. RulelD 27-IB Results 6 

37. RulelD 24-IB Results 5 


Did Not Eire 
Did Not Eire 
Fired 
Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Fired 

Did Not Fire 
Did Not Fire 
Fired 

Did Not Fire 
Fired 

Did Not Fire 
Did Not Fire 
Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
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38. RulelD 21-IB Results 4 


Did Not Fire 


39. RulelD 17-IB Results 3 Did Not Fire 

40. RulelD 11-IB Results 2 Did Not Fire 

41. RulelD 3-IB Results 0 Did Not Fire 

RulelDs 0-40 were each evaluated and either fired or not fired. The originating rule (Step 
1. IB Results 2.1) to begin the sourcing Did Not Fire in Step 32. Despite the ruleset 
finding its result after Step 34 when RulelD 35 Fired, the remaining rules are still 
evaluated in the ruleset for completeness. The RulelD 35 for IB Results 0.2 produced the 
expected result for this query of “Vessel Results from Unclassified IB with ID Injection 
for Port of San Diego.” This query effectively shows that the ruleset does intervene and 
provide for injection of data to prevent the misuse case. This eliminates the ability of the 
Harbormaster to infer information from the system and regains the safety of our 
information flows. 

3. Additional Use Is Excluded 

The original functionality is maintained by the system, despite the incorporation 

of our re-architecting and the implementation of the ID and its ruleset. To show that this 

still works as it did prior to this, we will process a query using the following parameters: 

Type of query: Destination Port 

Role / Actor: Harbormaster 

Location: San Diego 

Security Level: Unclassified 

Alert Present: False 

Alert Classification Level: Not Applicable 
Expected Result: “Invalid Query!” 


The expected result from this query and the RuleML execution is an IB response 
of “Invalid Query!” to the user. The trace of this query execution through the ruleset can 
be seen in Appendix D, which depicts the query and ruleset using RuleManager’s 
Interactive Rule Map functionality. In Appendix D, the detailed view of the trace also 
shows the individual variables and term s from within each rule being sourced as the 
engine completes its evaluation. These terms are referenced by the individual rule and 
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then evaluated to determine the end result for each rule. For this query, 
Return_IB_Results is the main variable (and expressed at the root of the rule tree) that is 
sourced from the ten different IB Result rules. Those rules were designed to replicate the 
external services that were not implemented for this research. Each IB Result rule can 
begin the trace to evaluate down to the base predicates (terminals in a CFG) that are 
necessary to resolve or decide the rule. This may be iterative in stepping through other 
rules to source the necessary values for the rule in question. In the first query instance, 
the IB Results 2.1 rule (RulelD 38) is the rule chosen to begin the sourcing of 
Return_IB_Results. The trace is as follows: 

1. RulelD 38-IB Results 2.1 Sourced 


2. RulelD 40-HM Query is Invalid 

3. RulelD 32-SD Harbormaster query is valid origination 2 

4. RulelD 30-SD Harbormaster query is valid origination 

5. RulelD 28-SD Harbormaster query is valid destination 2 

6. RulelD 25-SD Harbormaster query is valid destination 

7. RulelD 22-Oakland Harbormaster query is valid origination 2 

8. RulelD 18-Oakland Harbormaster query is valid origination 

9. RulelD 13-Oakland Harbormaster query is valid destination 2 

10. RulelD 4-Oakland Harbormaster query is valid destination 

11. RulelD 39-EWO query is invalid 

12. RulelD 20-EWO query is valid 2 

13. RulelD lO-EWO query is valid 

14. RulelD 15-Query Invalid 

15. RulelD 7-Query is Valid 

16. RulelD 38-IB Results 2.1 


Fired 

Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Did Not Fire 
Fired 

Did Not Fire 
Did Not Fire 
Fired 

Did Not Fire 
Did Not Fire 


17. RulelD 36-IB Results 0.3 
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Did Not Fire 



18. RulelD 35-IB Results 0.2 

Did Not Fire 

19. RulelD 34-IB Results 0.1 

Did Not Fire 

20. RulelD 27-IB Results 6 

Fired 

21. RulelD 24-IB Results 5 

Did Not Fire 

22. RulelD 21-IB Results 4 

Did Not Fire 

23. RulelD 17-IB Results 3 

Did Not Fire 

24. RulelD 11-IB Results 2 

Did Not Fire 

25. RulelD 3-IB Results 0 

Did Not Fire 


RulelDs 0-40 were not all evaluated for this query. The resultant value for the IB did not 
require information or variables from part of the ruleset in this query. Because we did not 
allow for actors outside of the scope of our scenario, the query processed was filtered by 
the ID and deemed Invalid. The originating rule (Step 1. IB Results 2.1) to begin the 
sourcing Did Not Fire in Step 16. Despite the ruleset finding its result after Step 20 when 
RulelD 27 Fired, the remaining rules for IB Results are still evaluated in the ruleset for 
completeness because they contain the same sourcing predicates that are used by the 
other IB Result rules and map to the final Return_IB_Results variable. The RulelD 27 for 
IB Results 6 produced the expected result for this query of “Invalid Query!” This query 
and the trace of our RuleML ID ruleset provide a clear and convincing argument that the 
ruleset does not support unintended usage or additional functionality that would not be 
supported by the original implementation. 

C. SUMMARY 

In order to support the goal of information sharing, we must not only consider 
information releasability, but non-disclosure of other information. The flexibility that is 
offered through the Information Declassifier and its execution of our rule base for all 
Information Broker interactions provides a positive step toward our ultimate goal of 
secure information sharing. We have clearly shown through these three test cases the 
viability of using RuleML as a CDS information flow control specification language and 
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particularly within a SOA-based environment. The flexibility of RuleML to account for 
the de-classification problem, resultant from the BLP tranquility principle, is limited only 
by the developmental ability of the human drivers creating the underlying policy in 
RuleML. 
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VII. CONCLUSION 


A. CONTRIBUTIONS 

In this research, we have demonstrated that by introducing the contributions listed 
below the safety properties of a mixed model access control, SOA-based, MLS system 
can be preserved, despite emergent challenges resultant from the composition of those 
disparate access controllers in order to facilitate information sharing. Table 12 provides a 
summary of the contributions of the research presented in this dissertation. 

The specific contributions of this work are: 

1. Developed and Used a New Methodology for Security Analysis using 
UML-based Use Case Analysis to Direct the Re-architecting of a 
System for the Preservation of Safety 

The methodology of security analysis using UML Use and Misuse Cases, allows 
for tailoring of security policies and mitigating the “highest cost” risks for information 
flow while still enabling trusted sharing. UML-based Use Case security analysis has not 
been applied in a MLS, SOA-based venue and this work utilizes that approach as an 
exemplar to provide for a greater access to information and increased sharing among 
disparate security domains. In order to support inviolate information flows to the security 
policy, and to overcome the tranquility property associated with traditional MLS systems, 
we demonstrate that Radiant Alloy needs to use an information declassifier. 
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Contribution 

❖ Provide a method for 
security analysis using 
UML Use Case Analysis 
to direct the re¬ 
architecting of a system 
for the preservation of 
safety. 

♦♦♦ Incorporate a process 
to allow for the 
prioritization of 
information flows and the 
“safe” composition of 
mixed access control 
models. 

<♦ Create business 
process rules, using 
RuleML to specify 
allowed information 
flows and to restrict 
flows that enable 
leakage of 
information from 
emergent behaviors, 
and facilitate sharing 
between systems. 

Validation of the 
system re-architecting 
through the conduct of 
a Regression Test to 
provide verification of 
RuleML content based 
query injection and 
filtering. 

Impact to 
DOD 

*t* Allows for tailoring 
security policies and 
mitigating the “highest 
cost” risks for 
information flow while 
still enabling trusted 
sharing. 

Opens the information 
sharing infrastructure to 
more DOD organizations. 

❖ Allow greater 
control of Need to 
Share / Need Not to 
Share information 
within domains. 

<♦ Increase speed of 

information 

dissemination. 

❖ Address high 
tempo of battle and 
change in situation for 
MDA instances. 

*1* Build basis of 
confidence for services 
use/reuse with respect 
to the Information 
Broker and its 
associated rule engine. 

❖ Build basis of 
confidence for services 
use/reuse with respect 
to the Information 
Broker and its 
associated rule engine. 


♦♦♦ Utilizes a process in a 
new domain and to 

<♦ Extends an open- 

<♦ Automatically 


provide for a greater 

source, XML-based, 

provide Information 


granularity of access to 

business process 

Broker web services a 

Impact to 

information. 

language to 

means of information 

Software 

❖ Allows engineers and 

facilitating the 

sharing and 

Engineering 

composition of access 

information filtering 


developers to combine 

controllers and the 

that is not available 


“best of’ practices in 

safety of the 

within individual 


their design of an 

associated models. 

access control models. 


information system. 




Table 12. Research Contribution Summary 
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2. Developed a New Process to Allow for the Prioritization of 
Information Flows and the “Safe” Composition of Mixed Access 
Control Models through a Re-architecting of the System 

Through the process of prioritizing the information-flow needs within a system, 
we can tailor the composition of different access control models to support required 
flows. This effectively opens the information sharing infrastructure to more DOD 
organizations and provides a means for cooperation and more real-time passing of 
information between agencies. This process also helps engineers and developers combine 
“best-of’ practices in their design and implementation of an AIS. The idea of 
prioritization is based on the risk analysis and risk tolerances of the stakeholders. The 
allowable “exceptions” to our baseline policies are considered as the only permissible 
extensions and ultimately determine what is safe for the system. The method shown in 
this research uses RuleML to enforce this policy. The need for sharing and the need to 
maintain security must be balanced to provide an operationally useful system that will 
still uphold the desired and specified safety for information flows. 

3. Created a New Process for the Development of Business Process 
Rules, using RuleML to Specify Allowed Information Flows and to 
Restrict Flows Enabling Leakage of Information from Emergent 
Behaviors and Facilitate Sharing between Information Systems 

To support the development of an information declassifier, we provide a policy- 
based framework to do so using RuleML [15]. By developing, implementing and 
enforcing business process rules through the use of RuleML, we realize a greater control 
of our information flows. The rule engine provides for a greater granularity of Need (Not) 
to Share for information within domains, facilitating the dissemination of information and 
providing increased speed of information flow to allow a greater use of “real-time” 
information, compared with traditional MAC-only policies. Current systems cannot 
support this level of information sharing and traditionally use a workaround (i.e., 
sneakernet) to meet user requirements. The extension of an open-source XML-based 
business process language to facilitate the composition of access controllers and the 
safety of the associated models provides a useful tool for software engineers in system- 
architecting efforts. 
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4 . 


Provided a Process that Allows Engineers to use Decision Tables or 
Other Methods to Develop Simple Propositions to Express Desired 
Process and Information Flows that can be Formed into Executable 
RuleML 

With the re-architecting of an information system, it is necessary to provide a 
convincing argument that the RuleML specification supports the system’s required 
information flows. By creating business process rules with RuleML to support the 
sharing of information within the system, we can show that all prior capabilities and 
intended flows are still available to the user, yet there are no unintended flows that result 
in violation of the safety property. This is an extension of the work conducted on the 
hook-up theorem for multilevel security with respect to inference control and the 
composability of restrictiveness for security policies [41]. This must be done to build a 
basis of confidence for services to be used (and reused) with respect to the Information 
Broker and its associated rule engine based Information Declassifier service. By 
regression testing, which includes running the ruleset with a sample data set, we can 
verify that our security use case is correct. This is necessary to help establish a basis for 
certification of information systems at high assurance levels. The rule-based. Information 
Declassifier service helps to automatically provide Information Broker web services with 
a means of information sharing and information filtering that is not available within 
individual access control models, and to ensure the safety of information flows in mixed 
model access control systems. This included the validation of the concept system re¬ 
architecting through the conduct of a regression testing verification and a simulation of 
RuleML content-based query injection and filtering, whose results verified the rule 
structure and usage of RuleML as a specification language. 

B. FUTURE WORK 

Research and engineering development remains to be done to provide for the 
seamless integration of disparate domain, mixed model access control information 
systems with high assurance information sharing as we envision. RuleML provides a 
technically feasible way of specifying cross-domain information flow control policies and 
for implementing an information declassifier, but work remains to be done to fully 
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explore how to leverage the power of RuleML. In addition, there are many specialty areas 
that attempt to use cross-domain solutions for integration of repositories and information 
sharing. While each of these potential areas offers great potential, much of the realization 
involves the willingness to partner and share between disparate organizations, and hence 
the solution to the problem cannot be purely technical. 

1. Malware and Advanced Persistent Threat Correlation 

Malware has become a pervasive element in computing today and a key element 
in gaining access to a protected network. The hardest threat to defend becomes the 
advanced persistent threat (APT), which is typically state-sponsored. This APT is 
resourced, well-trained, and active in state-sponsored entities. The effort to defend an 
enterprise network against these threats and the services being offered to assist in this 
process are continually growing. The resources required to defend against malware and 
hackers in terms of monetary and overall resource cost, time, and scope of effort have 
increased dramatically each year and the expertise of the APT heightens this effort even 
more. The effort is asymmetrical, where the defender has to determine what to defend 
and how to defend against an infinite (in theory) number of possible attacks, but the 
attacker only has to find one or a few exploitable vulnerabilities in order to exploit the 
network security. While the government and private industry have gone in different 
directions with tracking and reporting efforts, the defense techniques, the threat activity, 
and threat actors are the same. Several challenges exist, ranging from political, legal, and 
policy (e.g., antitrust laws) that must be overcome before technical solutions can be 
applied. By enabling information sharing and integration of disparate tracking efforts, we 
could realize an economy of scale in these defense efforts, as well as provide much better 
intelligence against these known threats. 

The Department of Defense (DOD) and Department of Homeland Security (DHS) 
established a voluntary sharing program for cyber incidents with many industry partners. 
This is referred to as the Defense Information Base (DIB) and consists of companies such 
as Northrop Grumman, Raytheon, and Boeing. These DIB participant companies have a 
strong partnership for threat detection and incident sharing among themselves, but they 
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are only given limited scope information from government sources like the Federal 
Bureau of Investigation (FBI), and the National Security Agency (NSA) that affords them 
contextual insight within their own monitoring and network defense practices. However, 
this effort does not allow for disclosure of key elements that would save time, effort, and 
financial resources among the partners. Additionally, these same partners are conducting 
reverse malware analysis and reporting on the details of the threats and malware 
encountered within their networks, yet the DOD and DHS systems and policies do not 
currently support that level of bi-directional sharing. By reducing the scope and limiting 
the details, these DIB partners are being subject to and penetrated by cyber threats that 
could be avoided with additional sharing. Much of the analysis of the threats is redacted, 
as are the pseudonyms used between government and DIB partners. This is the primary 
cause of duplication of effort and a much slower response and reaction time to realized 
threats for U.S. national security. 

By enacting a trusted sharing system with an information broker and an 
information declassifier as described in this research, this partnership could be greatly 
enhanced without risk of exposing need-not-to-share type information across non¬ 
government partners and between DIB member companies. The research opportunity for 
synchronizing the disparate tracking repositories for known malware and how that could 
be better shared through trusted connectors and an established RuleML-based security 
policy could have a significant effect on the DOD and private industry. 

2. Distribution of Services and Rule Sourcing 

Our research considers a localized RuleML ruleset. This ruleset was not 
established as a service, but only tested for viability as a potential information flow 
policy specification language for the implementation of the Information Declassifier. One 
of the most needed areas to be covered as an extension of this work is for a full-scale 
implementation. This implementation should include distributed services and distributed 
rule sourcing. The work should replicate the services of a SOA system and have rules 
access different services for firing and decisions. Our work replicated the sourcing of user 
attributes during rule evaluation and execution, yet this is an area of great concern for a 
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MLS ID. This would be useful in a distributed environment and give a viable argument 
for information releasability being safe. The full-scale system should include a 
distribution and versioning of the de-classification policies in which every agent runs its 
own policy and calls the other one for the appropriate invocation of rules. This way each 
agent only exposes those aspects of the policy that they are permitted to expose. One risk 
associated with this distribution and remote sourcing of rules is with failure and 
divergence. When we begin to rely on externally sourced services to provide input for 
rule-evaluation, we risk that the service will hang while waiting for a response. This 
response may be delayed somewhere in the network, or even worse, the response may be 
a circular reference and be dependent on the same service that had invoked it for part of 
its evaluation. This dependency on variables sourced in other rules or other services for 
successive calls is an area that also needs to be addressed as a function of the distribution 
of rule sourcing and the full implementation of services. The replication of the ID needs 
to be done in tandem with sharing the ruleset that is created between IB domains. Since 
the IB is replicated and the ID will be replicated, an issue can arise in which the ruleset 
becomes out of synch and the rules from a higher level are not the same as the rules from 
the lower, since we need to evaluate different risks at disparate domain levels. 
Additionally, the vessel information that is processed could be sourced from a working 
U.S. Navy system like MASTER. This system integrates vessel data with the MIEM and 
could easily populate a query with real data. The MIEM schemas can also allow for a 
finer granularity of rule based on other viable vessel data fields. Ultimately, the 
distributed system version would play favorably toward a true and expressed need in the 
DOD and Homeland Defense communities [5]. 

3. Using RuleML for a CDS Data Sanitization Policy 

There are many venues where this effort can help to realize the information 
sharing needs of multiple organizations. In particular, we often need to focus on the 
releasability of information and not just injection or filtering. One of the areas where this 
research work can be extended is data sanitization between domains. This methodology 
and development of rules can be tailored to meet the business process needs in just such a 

manner. Oftentimes federal agencies are tasked to work with state and local agencies to 
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conduct drug enforcement or other special operations. Such scenarios provide fertile 
ground for exploring information releasability and the use of a sanitizer. Usually when 
working with the DOD, a state and local agency will provide information to the DOD. By 
our current policies and classification marking system, as soon as the DOD agency 
obtains that information, it becomes classified at a higher level than what we can release 
back to the state or local agency. This is similar to the scenario we worked with in our 
research, yet the primary reason the DOD is involved is to support the state and local 
agencies and not the other way around. In this case, we may be able to sanitize certain 
fields (using XML tags) of data that DOD cannot release back to the state or local 
agency. But, if we look at the origination of the data and the mission scenario, we should 
be able to tailor our ruleset accordingly while preserving our ability to enforce our 
security policy. An additional area may be the consideration of time in the release of 
information. When an action has already occurred, what value does the information have? 
Adding a temporal constraint or aspect to a ruleset would help to enforce the time value 
of information and to enhance our ability to share without violation of policy. This would 
raise the complexity of analyzing the data itself for queries and rule execution, but would 
also help to alleviate the inevitable progression of data to the high side of our 
classification systems. 

4. Formal Patterns for Access Control Model Composition 

A key area of possible work exists with the integration of disparate access control 
models. This integration would be served best through the development of a pattern for 
how a set of access control models can be combined. Software engineering has been the 
benefactor of both design and architectural patterns for years in the creation of new 
systems. Patterns trace their origins back to Alexander’s work on urban planning and 
architecture, and software patterns in particular were brought to prominence in 1994, with 
the Gamma, Helm, Johnson, and Vlissides’s (the Gang of Four) book of Design Patterns, 
which was geared toward object oriented programming. [70] Patterns are a best practice 
approach to solving a recurring problem in a particular domain or context. Design 
patterns are a generalized approach to solving a problem that must be implemented each 


138 



time they are used. These patterns are used to address a specific element of the system 
design. In [70], four essential elements of a design pattern include: 

1. A meaningful name 

2. A description of the problem to show how and when the pattern should be 
applied 

3. A solution description of the parts of the design solution, relationships, 
and responsibilities. 

4. A statement of consequences including the results and the trade-offs of 
using or applying the pattern. 

This standard pattern format, to which we generally adhere, helps to explain and 
document the purpose, intent, consequences, and other referencing patterns. Each pattern 
discussion includes; intent, motivation, applicability, structure, participants, 
collaborations, consequences, implementation, sample code, known uses and related 
patterns. Patterns can be used to describe a system structure that meets the design needs 
of an application in a given domain. Almost as a tribal knowledge is passed along, the 
pattern use and standardized format allow for an easy to use and robust set of information 
about rationale, consequences, and related decisions for system design. The pattern also 
allows for a faster method of documentation, since many of the aspects of “good” 
documentation are included in the original pattern description. This type of 
documentation for the composition of disparate access controllers could be of tremendous 
benefit to the security personnel tasked with integrating multiple systems. 

A key benefit to pattern use is the ability to tailor the purpose of the pattern to 
meet differing quality aspects or critical requirements, such as: performance, security, 
safety, availability, reliability, maintainability, or dependability. Inherent with this 
focused approach to maximizing or targeting one aspect is that the others are, of course, 
affected. This affect may be positive (e.g., security is patterned, but safety is also 
enhanced) or negative (e.g., security is patterned, but performance is degraded). By 
utilizing the idea of patterns in our composition of access control models we can afford 
system and security policy designers the ability to rapidly create security policies that 
will work well together and make transparent the engineering tradeoff decisions that need 
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to be made. The creation of an ID service and its associated ruleset using a pattern to seed 
the development is ideal. The composition pattern should probably include areas where 
the access control models conflict between themselves, the overall information flows and 
recommendations for how those conflicts can and should be resolved. Any ambiguity in a 
ruleset is bad. The pattern idea extended to the ID ruleset can allow for conflict-of- 
interest mitigation (i.e., using rules to decide between conflicts) between systems using 
differing access control models that are required to share information seamlessly. If we 
continue to rely on the best efforts of those who are designing a system and trying to 
integrate disparate policies without such a template, then we risk that policy being 
unsound or incomplete. 

This patterning would also allow for a repeatable methodology for misuse/breach 
of the safety property between disparate controllers. Ultimately, we face a compromise 
between the effectiveness of our security mechanisms and controls and the operational 
effectiveness of the system. A pattern approach to provide a baseline for the mandated 
policy specified with RuleML (for the Information Declassifier) would help to meet our 
need for information sharing. 

5. RBAC for Mandatory Access Control of Query Sets 

Developing RBAC-based permissions for queries to the system and even rules 
based upon roles for within a specific domain is a promising area for further research. By 
using role-based permissions on a set of queries (i.e., a single query or a group of n 
queries) assigned to a particular role. This would, in effect, limit the scope of queries by 
what role the user plays in the system and also add a greater granularity with the access 
control assisting the information declassifier to fulfill its duties. This would leverage the 
usefulness of RBAC, where we do not need to change the role-permission mappings very 
often. Instead, we merely change the user-role mappings for our system. If we could map 
a set of queries as just another object in the system, then the role could be given specific 
access to that object (i.e., a restricted set of queries). Then the Information Declassifier 
that we have described in this work would still be used to filter and inject information 
between domains. For example, a Harbormaster would be given query ability for two to 
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three queries and RuleML could be used to further filter those role-based queries for 
location (e.g., the role-based query allows for queries about ships inbound and outbound 
for any harbormaster to use, but the San Diego HM only gets results for San Diego as 
filtered by the ID). Additionally, we could utilize web services to invoke separate IDs 
based on the role-permission mapping by changing the port and addressing of the 
individual queries based on the role the user is performing. This would allow for a more 
structured filtering ability, yet it would add to the complexity of designing numerous 
rulesets for multiple ID services at the same classification-domain level. 

6. Automatic Generation of Cover Stories 

The use of obfuscation through polyinstantiation to prevent inference attacks and 
general inference from authorized use is well known. Another area where a RuleML 
application of policy could be implemented is with the automatic generation of cover 
stories to promote data hiding. By allowing the automatic generation the system will not 
continue to produce the same consistent result from a query or interaction. This will also 
prevent the ability to infer information from the system from both the lack of information 
presented and from the presence of known invalid information. 
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APPENDIX A. RULESET EXPLICATION 


RulelD 0 is titled Alert Not Valid for Role Location. This rule is intended to 
eliminate possibilities for Alert Messaging responses that are not valid for our scenario. If 
an Alert exists for Los Angeles in the system (at a higher level IB), then this rule turns 
that notification to FALSE, since it does not apply to the port of San Diego. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert Not Valid for Role Locat ion</ind> 
</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/10/2009</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#information_Declassifier" /> 

</ scope> 

<oid>ruleO</oid> 

<!— Alert Not Valid for Role Location —> 

<if> 

<0r> 

<0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 
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type="string">"Alert Exists (SECRET IB) for Port of 

Los Angeles"</ Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of Los 

Angeles "</Ind> 

</rhs> 

</Equal> 

</0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"No Alert Exists"</Ind> 

</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 11. RuleML code for RulelD 0 

RulelD 1 is titled Alert Notification is Present. This rule is intended to set the 
variable Query_Requires_Data_Insertion to TRUE, if the higher level IB possesses an 
Alert Message. In this ruleset, the external reference is not made, but invoked through the 
use of an internally generated variable for the sourcing. 

<Rule 

styles" active" 
evaluation=" strong"> 
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<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>Alert Notification is Present</Ind> 
</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : date"> 

<Ind>2/2 6/2 0 0 9</Ind> 

</Fun> 

</Fxpr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</scope> 

<oid>rulel</oid> 

<!— Alert Notification is Present —> 

<if> 

<Fqual> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_Insert ion</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</ Ru1e > 

Listing 12. RuleML code for RulelD 1 
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RulelD 2 is titled Est Location for Role. This rule is intended to fix the assignment of the 
user’s role location to the results being returned from the IB. This will allow for 
additional filtering to match the user’s location with vessel results from the data 
repositories that match with origination or destination ports. 


<Rule 

style="act ive" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>Est Location for Role</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rule2</oid> 

<!— Est Location for Role —> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Oakland"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 
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<Atom> 

<Rel>Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="st ring" >" San Diego"</ Ind> 
</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 13. RuleML code for RulelD 2 


RulelD 3 is titled IB Results 0. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expeeted result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Unelassified IB with ID Injection for 
Oakland Alert.” This is done after checking the user’s security level and for the presence 
of an alert for this location. This rule was created to allow for Harbormaster queries from 
the port of Oakland as an extension to the San Diego port aeeounted for in our scenario. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<Ind>IB Results 0</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule3</oid> 

<!— IB Results 0 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (IS IB) for Port of 

Oakland"</Ind> 

</rhs> 
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</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Unclassified IB with ID 
injection for Oakland Alert"</ind> 

</Atom> 

</do> 

</Rule> 


Listing 14. RuleML code for RulelD 3 


RulelD 4 is titled Oakland Harbormaster query is valid destination. This is one of the 
rules used as extension to our primary scenario, which would allow for the port of 
Oakland queries to also work in the system. It is used to verify the user role, the role 
location, the PDF decision, and the type of query before deciding that it is a valid query 
and should be processed by the IB. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<ind>Oakland Harbormaster query is valid 
destinat ion</ ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2 0 0 9</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 
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uri="#Inf ormation_Declassif ier" /> 

</ scope> 

<oid>rule4</oid> 

<!— Oakland Harbormaster query is valid destination —> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

< Re1 > Us e r_Ro1e </ Re1 > 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Harbormaster"</ ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Locat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Oakland"</ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Dest ination_Port Query"</ ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 
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<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Dest inat ion_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 15. RuleML code for RulelD 4 

RulelD 5 is titled PDP Decision. This is an externally soureed rule that would be 
completed by the Policy Decision Point service in our SOA system. It is used, based on 
the variables it is sourced with, to provide a decision for that user’s access to resources in 
the system. In this implementation, it is not refereneed from an actual external PDP 
serviee. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<ind>Policy Decision Point</ind> 
</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 
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uri="dc : date"> 

<Ind>2/2 6/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 
</scope> 

<oid>rule5</oid> 

<!— Policy Decision Point —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Re1 >Us e r_Ro1e_P e rmi ssions</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="bool">true</ lnd> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

<lnd 

type="bool">true</ lnd> 

</Atom> 

</do> 

</ Ru1e > 


Listing 16. RuleML code for RulelD 5 

RulelD 6 is titled Positive ID Response to IB for Alert. This rule is used to indicate a 
positive response to the presence of an Alert Message at a higher level IB and verifies 
that the query to the IB is valid based on the roles active in our system. This rule ensures 
that the IB response that was previously returned directly to the user is now processed 
through the ID and missing data is injected to the query if necessary, to eliminate the 
Misuse Case and as a <Prevent> feature of our Security Use Case. This rule is designed 
to verify other rules that determine if the query to the system is valid, and if the response 
from the higher level IB requires the system to inject data before processing the query 
response. It also checks if the query requires data insertion, which is sourced from the 
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higher level IBs. If both of these conditions are TRUE, then the IB that received the query 
is informed that its response to the user must wait for the injection messaging from the ID 
service prior to returning results to the user. 


<Rule 

sty le=" active" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<ind>Posit ive iD Response to iB for Aiert</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>i2/5/2008</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier" /> 

</ scope> 

<oid>ruie6</oid> 

<!— Positive iD Response to iB for Aiert —> 

<if> 

<And> 

<Atom> 

<Rei>Vaiid_Query</Rei> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rei>Query_Requires_Data_insert ion</Rei> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rei>iB_Response_Wait</Rei> 

<Var>Subject</Var> 

<ind 

type="booi">true</ind> 
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</Atom> 

</do> 

</Rule> 

Listing 17. RuleML code for RulelD 6 

RulelD 7 is titled Query is Valid. This is a filtering rule and is used to verify that the user 
(EWO or Harbormaster) is requesting an allowable query. It is sourced from two other 
rules, whieh eheck if the query against each actor’s allowable query set, to determine 
validity. 


<Rule 

style="act ive" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>Query is Valid</Ind> 
</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : date"> 
<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 
</ scope> 

<oid>rule7</oid> 

<!— Query is Valid —> 

<if> 

<Or> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 
<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 
<Var>Subject</Var> 
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</Atom> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 
</Atom> 

</do> 

</Rule> 


Listing 18. RuleML code for RulelD 7 


RulelD 8 is titled Alert Notification is Absent. This rule is intended to set the variable 
Query_Requires_Data_Insertion to FALSE, if the higher level IB does not possess an 
Alert Message. In this ruleset, the external reference is not made, but invoked through the 
use of an internally generated variable for the soureing. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert Notification is Absent</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>2/26/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier" /> 

</ scope> 

<oid>ruie8</oid> 

<!— Aiert Notification is Absent —> 
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<if> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</ Ind> 

</rhs> 

</Equal> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_Insert ion</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 


Listing 19. RuleML code for RulelD 8 


RulelD 9 is titled Alert SD Secret IB. This rule is used to verify that when an alert is 
present at the Secret level IB, intended for San Diego, and the requestor is at the 
Unclassified security level, that the Alert_Present_Response is set to TRUE. This will 
indicate to the ID and IB that an alert is present that pertains to the user query, and that 
the user is below the alert’s classification level. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert SD Secret IB</Ind> 
</Fun> 

</Expr> 

<Expr> 
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<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</ scope> 

<oid>rule9</oid> 

<!— Alert SD Secret IB —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of 

San Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</ Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 
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<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</ Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 20. RuleML code for RulelD 9 


RulelD 10 is titled EWO Query is Valid. This is a filtering rule and is used to verify that 
the user fulfilling the EWO role is requesting an allowable query. It is cheeked against 
the actor’s allowable query set, to determine validity. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<Ind>EWO query is valid</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 
</ scope> 
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<oid>rulelO</oid> 

<!— EWO query is valid —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Re 1 >U s e r_Ro1e </ Re1 > 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"EWO"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 21. RuleML code for RulelD 10 
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RulelD 11 is titled IB Results 2. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Secret IB and Unclassified IB with ID 
Injection for Oakland Alert.” This is done after checking the user’s security level and for 
the presence of an alert for this location. The IB, in this case, would return its regular 
result from both the Unclassified and Secret level IBs (since the user is at the Secret 
level), and then the required Alert Message insertion from the TS IB. This rule was 
created to allow for Harbormaster queries from the port of Oakland as an extension to the 
San Diego port accounted for in our scenario. 


<Rule 

style="act ive" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB Results 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 
</ scope> 

<oid>rulell</oid> 

<!— IB Results 2 —> 

<if> 

<And> 

<And> 
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<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS iB) for Port of 

Oakiand"</ind> 

</rhs> 

</Equai> 

</And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Location</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Oakiand"</ind> 

</rhs> 

</Equai> 

</And> 

</if> 

<do> 

<Atom> 

<Rei>Return_iB_Resuit s</Rei> 
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<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Secret IB and 
Unclassified IB with ID Injection for Oakland Alert"</Ind> 
</Atom> 

</do> 

</ Ru1e > 


Listing 22. RuleML code for RulelD 11 


RulelD 12 is titled Negative ID Response to IB for Alert. This rule provides an 
acknowledgment of a negative result for alert message presence. This is used to trigger 
other rules in the ruleset and to ensure that the ID returns a result in all cases. Without 
this rule, it is possible for the ID to return nothing, which allows for ambiguity in the 
ruleset. It cheeks if the query requires data insertion, which is sourced from the higher 
level IBs. If FALSE, then the IB that received the query is informed that its response to 
the user does not need to wait for the ID injection messaging prior to returning results to 
the user. 


<Rule 

sty le=" active" 
evaluat ion=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Negat ive ID Response to IB for Alert</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormatIon_De classifier" /> 
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</scope> 

<oid>rulel2</oid> 

<!— Negative ID Response to IB for Alert —> 

<if> 

<And> 

<Atom> 

<ReI>VaIid_Query</ReI> 

<Var>Subject</Var> 

</Atom> 

<EquaI> 

<Ihs> 

<Atom> 

<ReI>Query_Requires_Data_Insert ion</ReI> 
<Var>Subject</Var> 

</Atom> 

</Ihs> 

<rhs> 

<Ind 

type="booI">f alse</ Ind> 

</rhs> 

</EquaI> 

</And> 

</if> 

<do> 

<Atom> 

<ReI>IB_Response_Wait</ReI> 

<Var>Subject</Var> 

<Ind 

type="booI">f alse</lnd> 

</Atom> 

</do> 

</RuIe> 


Listing 23. RuleML code for RulelD 12 


RulelD 13 is titled Oakland Harbormaster query is valid destination 2. This rule is 
almost a duplicate of RulelD 4, but is used to support an alternative method of 
designating roles. In this case, if the role is listed as Harbormaster Oakland, instead of the 
generie Harbormaster designation, then the rule will proeess similarly. This is one of the 
rules used as extension to our primary scenario, whieh would allow for the port of 
Oakland queries to also work in the system. It is used to verify the user role, the role 
location, the PDF decision, and the type of query before deciding that it is a valid query 
and should be processed by the IB. 


<RuIe 

sty Ie=" active" 
evaluat ion="strong"> 
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<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>Oakland Harbormaster query is valid destination 

2</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Fxpr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</ scope> 

<oid>rulel3</oid> 

<!— Oakland Harbormaster query is valid destination 2 —> 

<if> 

<And> 

<And> 

<Fqual> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster Oakland"</Ind> 

</rhs> 

</Equal> 

<Fqual> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Dest ination_Port Query"</ Ind> 
</rhs> 
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</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Locat ion</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Oakland"</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Dest inat ion_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Locat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 24. RuleML code for RulelD 13 


RulelD 14 is titled PDF Decision 2. This is an externally sourced rule that would be 
completed by the Policy Decision Point service in our SOA system. It is used, based on 
the variables it is sourced with, to provide a deeision for that user’s aceess to resources in 
the system. In this implementation, it is not refereneed from an actual external PDP 
service, and this rule is intended to provide a positive response to the service check for a 
negative response. 


165 



<Rule 

sty le=" active" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<ind>Poiicy Decision Point 2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>2/26/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier" /> 

</ scope> 

<oid>ruiei4</oid> 

<!— Poiicy Decision Point 2 —> 

<if> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Permissions</Rei> 
<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="booi">f aise</ind> 

</rhs> 

</Equai> 

</if> 

<do> 

<Atom> 

<Rei>PDP_Decision</Rei> 

<Var>Subject</Var> 

<ind 

type="booi">f aise</ind> 

</Atom> 

</do> 

</Ruie> 
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Listing 25. RuleML code for RulelD 14 


RulelD 15 is titled Query is Invalid. This is a filtering rule and is used to verify that the 
user (EWO or Harbormaster) is requesting an allowable query. It is sourced from two 
other rules, which check if the query against each actor’s allowable query set, to 
determine validity. This rule is intended to provide a positive response to the query eheck 
in the case of a negative response. 


<Rule 

sty le=" active" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<ind>Query invaiid</ ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<ind>3/i0/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier" /> 
</ scope> 

<oid>ruiei5</oid> 

<!— Query invaiid —> 

<if> 

<Or> 

<Equai> 

<ihs> 

<Atom> 

<Rei>HM_Vaiid_Query</Rei> 
<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 


167 



type="bool">true</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</ Ind> 
</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 26. RuleML code for RulelD 15 


RulelD 16 is titled Alert SD Secret IB 2. This rule is used to verify that when an alert is 
present at the Seeret level IB, intended for San Diego, and the requestor is at the 
Unclassified security level, that the Alert_Present_Response is set to TRUE. This will 
indicate to the ID and IB that an alert is present that pertains to the user query, and that 
the user is below the alert’s classification level. This rule is equivalent to RulelD 9 and is 
used to support an alternative method of designating roles. In this ease, if the role is listed 
as the generic Harbormaster, instead of the Harbormaster San Diego designation, then the 
rule will process similarly. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert SD Secret IB 2</Ind> 
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</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rulel6</oid> 

<!— Alert SD Secret IB 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert Exists (SECRET IB) for Port of 

San Diego"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Unclassif ied"</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 
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<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing 27. RuleML code for RulelD 16 


RulelD 17 is titled IB Results 3. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Secret IB and Unclassified IB.” This is 
done after cheeking the user’s seeurity level and for the presenee of an alert for this 
location. The IB, in this case, would return its regular result from both the Unclassified 
and Secret level IB’s (since the user is at the Secret level). 


<Rule 

style="act ive" 
evaluat ion="strong"> 
<label> 
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<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 3</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>2/2 6/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declass!tier" /> 
</scope> 

<oid>rulel7</oid> 

<!— IB Results 3 —> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</ Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 
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<Ind 

type=" st ring" >" Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Secret IB and 
Unclassified IB"</Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 28. RuleML code for RulelD 17 


RulelD 18 is titled Oakland Harbormaster query is valid origination. This rule is 
supports an alternative method of designating roles. In this ease, if the role is listed as 
Harbormaster Oakland, instead of the generic Harbormaster designation, then the rule 
will process similarly. This is one of the rules used as extension to our primary scenario, 
which would allow for the port of Oakland queries to also work in the system. It is used 
to verify the user role, the role loeation, the PDF decision, and that the query type is for 
an Originating Port before deciding that it is a valid query and should be processed by the 
IB. 


<Rule 

style="act ive" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<Ind>Oakland Harbormaster query is valid 
originat ion</ Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 
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<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</scope> 

<oid>rulel8</oid> 

<!— Oakland Harbormaster query is valid origination —> 
<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string"> "Harbormaster Oakland"</ ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Originat ing_Port Query"</ ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<ind 

type="bool">true</ ind> 

</Atom> 

<Atom> 
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<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Oakland"</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 29. RuleML code for RulelD 18 


RulelD 19 is titled Alert SD TS IB. This rule is established as a trigger within the ruleset 
to identify that an Alert Message is present and to verify the level of the Alert Message 
against the seeurity level of the user produeing the query. This rule is used to verify that 
when an alert is present at the Top Secret level IB, intended for San Diego, the requestor 
is at the Unclassified or Secret security level, and that the Alert_Present_Response is set 
to TRUE. This will indicate to the ID and IB that an alert is present that pertains to the 
user query, and that the user is below the alert’s classifieation level. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<Ind>Alert SD TS IB</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rulel9</oid> 

<!— Alert SD TS IB —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Top Secret "</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 
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type="string">"Harbormaster San Diego"</ Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing 30. RuleML code for RulelD 19 

RulelD 20 is titled EWO Query is Valid 2. This is a filtering rule and is used to verify that 
the user fulfilling the EWO role is requesting an allowable query. It is checked against 
the actor’s allowable query set, to determine validity. This rule is equivalent to RulelD 
10, but accounts for a different role naming convention. In this case, the user’s role is 
Electronic Warfare Officer, instead of EWO. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<Ind>EWO query is valid 2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 
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uri="#Inf ormation_Declassif ier" /> 

</ scope> 

<oid>rule20</oid> 

<!— EWO query is valid 2 —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic Warfare Off icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</ Ru1e > 
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Listing 31. RuleML code for RulelD 20 

RulelD 21 is titled IB Results 4. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Unclassified IB.” This is done after 
checking the user’s security level and for the presence of an alert for this location being 
FALSE. The IB, in this case, would return its regular result from the Unclassified-level 
IB. 


<Rule 

styles" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB Results 4</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 
</scope> 

<oid>rule21</oid> 

<!— IB Results 4 —> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 
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</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassified"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Unclassified 1B"</Ind> 
</Atom> 

</do> 

</Rule> 


Listing 32. RuleML code for RulelD 21 


RulelD 22 is titled Oakland Harbormaster query is valid origination 2. This rule is 
almost a duplicate of RulelD 18, but is used to support an alternative method of 
designating roles. In this case, if the role is listed as the generic Harbormaster, instead of 
the Harbormaster Oakland designation, then the rule will proeess similarly. This is one of 
the rules used as extension to our primary seenario, which would allow for the port of 
Oakland queries to also work in the system. It is used to verify the user role, the role 
location, the PDF decision, and the type of query is an originating port query before 
deeiding that it is a valid query and should be processed by the IB. 
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<Rule 

sty le=" active" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<ind>Oakiand Harbormaster query is vaiid origination 

2</ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2 0 0 9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier" /> 

</scope> 

<oid>ruie22</oid> 

<!— Oakiand Harbormaster query is vaiid origination 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster"</ind> 

</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Locat ion</Rei> 

<Var>Subject</Var> 

</Atom> 
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</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originat ing_Port Query"</ Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 33. RuleML code for RulelD 22 
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RulelD 23 is titled Alert SD TS IB. This rule is used to verify that when an alert is present 
at the Top Secret level IB, intended for San Diego, and the requestor is at the 
Unclassified or Secret security level, that the Alert_Present_Response is set to TRUE. 
This will indicate to the ID and IB that an alert is present that pertains to the user query, 
and that the user is below the alert’s classification level. This rule is equivalent to RulelD 
19 and is used to support an alternative method of designating roles. In this case, if the 
role is listed as the generic Harbormaster, instead of the Harbormaster San Diego 
designation, then the rule will process similarly. 


<Rule 

sty le=" active" 
evaluation^" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<ind>Alert SD TS iB 2</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2 0 0 9</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#information_Declassifier" /> 

</ scope> 

<oid>rule23</oid> 

<!— Alert SD TS IB 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 
<Var>Subject</Var> 
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</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego"</ Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 
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</do> 

</Rule> 


Listing 34. RuleML code for RulelD 23 


RulelD 24 is titled IB Results 5. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expeeted result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from TS IB, Secret IB and Unclassified IB.” 
This is done after checking the user’s security level is equal to Top Secret. The user in 
this case is authorized all data from each of the classification levels and does not require 
injeetion to the IB results. 


<Rule 

style="act ive" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB Results 5</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 
</ scope> 

<oid>rule24</oid> 

<!— IB Results 5 —> 

<if> 

<And> 

<And> 
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<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from TS IB, Secret IB, and 
Unclassified IB"</Ind> 

</Atom> 

</do> 

</Rule> 


Listing 35. RuleML code for RulelD 24 


RulelD 25 is titled SD Harbormaster query is valid destination. This rule is used to verify 
the user role as Harbormaster, the role location is San Diego, the PDF decision is TRUE, 
and the query is both valid and of the type Destination_Port_Query before deciding that 
it is valid and should be proeessed by the IB. 

<Rule 

sty le=" active" 
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evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>SD Harbormaster query is valid destinat ion</ Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declass!tier" /> 

</ scope> 

<oid>rule25</oid> 

<!— SD Harbormaster query is valid destination —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

< Re1 > Us e r_Ro1e </ Re1 > 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster"</ lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"San Diego"</ lnd> 
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</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port Query "</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Dest inat ion_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 36. RuleML code for RulelD 25 

RulelD 26 is titled Alert Oak Secret IB. This rule is established as a trigger within the 
ruleset to identify that an Alert Message is present and to verify the level of the Alert 


187 



Message against the security level of the user producing the query. This particular rule is 
used as an extension to our baseline scenario to account for users at the port of Oakland. 
This will indicate to the ID and IB that an alert is present that pertains to the user query, 
and that the user is below the alert’s classification level. 


<Rule 

style="act ive" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>Alert Oak Secret IB</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_De class! tier" /> 

</ scope> 

<oid>rule26</oid> 

<!— Alert Oak Secret IB —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert Exists (SECRET IB) for Port of 

Oakland"</lnd> 

</rhs> 

</Equal> 
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<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</ Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster Oakland"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing 37. RuleML code for RulelD 26 


RulelD 27 is titled IB Results 6. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rulebase with a sample query. In this case, 
it returns the IB result of “Invalid Query!.” This is done after checking the query validity 
from the ValidjQuery variable. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 
<label> 

<Plex> 
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<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB Results 6</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 
</scope> 

<oid>rule27</oid> 

<!— IB Results 6 —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">" Invalid Query! "</ Ind> 
</Atom> 

</do> 

</Rule> 


Listing 38. RuleML code for RulelD 27 
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RulelD 28 is titled SD Harbormaster query is valid destination 2. This rule is identical in 
functionality to RulelD 25, but supports the extended role convention using 
Harbormaster San Diego instead of the generic Harbormaster role. This rule is used to 
verify the user role as Harbormaster San Diego, the PDP decision is TRUE, and the type 
of query is Destination_Port_Query before deciding that it is valid and should be 
processed by the IB. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD Harbormaster query is valid destination 2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</scope> 

<oid>rule28</oid> 

<!— SD Harbormaster query is valid destination 2 —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 
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type="string">"Harbormaster San Diego"</ Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Dest ination_Port Query"</ Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"San Diego"</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Dest inat ion_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 39. RuleML code for RulelD 28 
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RulelD 29 is titled Alert Oak Secret IB 2. This rule is established as a trigger within the 
ruleset to identify that an Alert Message is present and to verify the level of the Alert 
Message against the security level of the user producing the query. It is identical in 
functionality to RulelD 26, but supports the generic role moniker of Harbormaster 
instead of Harbormaster Oakland. This particular rule is used as an extension to our 
baseline scenario to account for users at the port of Oakland. This will indicate to the ID 
and IB that an alert is present that pertains to the user query, and that the user is below the 
alert’s classification level. 


<Rule 

styles" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert Oak Secret IB 2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_De class! tier" /> 
</scope> 

<oid>rule29</oid> 

<!— Alert Oak Secret IB 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 
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<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET iB) for Port of 

Oakiand"</ind> 

</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Security_Levei</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Unciassif ied"</ ind> 

</rhs> 

</Equai> 

</And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster"</ind> 

</rhs> 

</Equai> 

</And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Location</Rei> 

<Var>Sub ject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Oakiand"</ind> 

</rhs> 

</Equai> 

</And> 

</if> 

<do> 

<Atom> 

<Rei>Aiert_Present_Response</Rei> 

<Var>Subject</Var> 

<ind 
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type="bool">true</Ind> 

</Atom> 

</do> 

</ Ru1e > 

Listing 40. RuleML code for RulelD 29 

RulelD 30 is titled SD Harbormaster query is valid origination. This rule is identical in 
functionality to RulelD 32, but supports the extended role convention using 
Harbormaster San Diego instead of the generic Harbormaster role. This rule is used to 
verify the user role as Harbormaster San Diego, the PDF decision is TRUE, and the type 
of query is Originating_Port_Query before deciding that it is valid and should be 
processed by the IB. This rule checks the query that is being processed and sets 
conditions to restrict the IB response as a result. This rule is designed to eliminate the 
user’s ability to repeatedly query the system to troll for information, or the lack of 
information, again a key element in preventing the Misuse Case. In the original system, 
queries were directly processed by the IB after entry. In the re-architected system, we 
reroute all queries through the ID (per Figure 26) where we begin the new data flow at 
continuation point I instead of direct processing by the IB in the original flow. In this 
case, the query and resultant data must include the Harbormaster’s port (either 
Origination or Destination) for details to be returned by the IB and ID. This is part of the 
<Detect> in the Security Use Case that we had to reroute queries in the system. This will 
prevent a Harbormaster from continually querying the system to get information about 
vessels from the system that do not directly pertain to his or her role (at his location) and 
his normal performance of duty. This rule verifies that the user is a Harbormaster from 
San Diego and conducting an Originating Port Query, which he is authorized because of 
his role’s duties and obligations, as well as a PDP service check to validate the role’s 
permissions to execute a basic query and to access information from the IB. The rule then 
establishes this as a valid query for the San Diego Harbormaster, while it also restricts the 
query response by limiting Vessel_Classification_Level to the User_Security_Level, and 
setting the field for Vessel_Originating_Port to the User_Role_Location, or in this case 
San Diego. 
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<Rule 

sty le=" active" 
evaluation=" strong" > 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD Harbormaster query is vaiid originat ion</ind> 
</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2 0 0 9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier" /> 

</scope> 

<oid>ruie30</oid> 

<!— SD Harbormaster query is vaiid origination —> 

<if> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster San Diego"</ind> 
</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>HM_Queries</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 
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type="string">"Originating_Port Query "</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"San Diego"</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing 41. RuleML code for RulelD 30 

RulelD 31 is titled Alert Oak TS IB. This rule is established as a trigger within the ruleset 
to identify that an Alert Message is present and to verify the level of the Alert Message 
against the security level of the user producing the query. It is identical in functionality to 
RulelD 33, but supports the generie role moniker of Harbormaster instead of 
Harbormaster Oakland. This particular rule is used as an extension to our baseline 
scenario to account for users at the port of Oakland. This will indicate to the ID and IB 
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that an alert is present that pertains to the user query, and that the user is below the alert’s 
classification level. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title" > 

<Ind>Alert OakTS IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</ scope> 

<oid>rule31</oid> 

<!— Alert OakTS IB —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 
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<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Locat ion</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 42. RuleML code for RulelD 31 


RulelD 32 is titled SD Harbormaster query is valid origination 2. This rule is almost a 

duplicate of RulelD 30, but is used to support an alternative method of designating roles. 

In this case, if the role is listed as the generic Harbormaster, instead of the Harbormaster 
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San Diego designation, then the rule will process similarly. This rule checks the query 
that is being processed and sets conditions to restrict the IB response as a result. This rule 
is designed to eliminate the user’s ability to repeatedly query the system to troll for 
information, or the lack of information, again a key element in preventing the Misuse 
Case. In the original system, queries were directly processed by the IB after entry. In the 
re-architected system, we reroute all queries through the ID (per Figure 26) where we 
begin the new data flow at continuation point I instead of direct processing by the IB in 
the original flow. In this case, the query and resultant data must include the 
Harbormaster’s port (either Origination or Destination) for details to be returned by the 
IB and ID. This is part of the <Detect> in the Security Use Case that we had to reroute 
queries in the system. This will prevent a Harbormaster from continually querying the 
system to get information about vessels from the system that do not directly pertain to his 
or her role (at his location) and his normal performance of duty. This rule verifies that the 
user is a Harbormaster from San Diego and conducting an Originating Port Query, which 
he is authorized because of his role’s duties and obligations, as well as a PDP service 
check to validate the role’s permissions to execute a basic query and to access 
information from the IB. The rule then establishes this as a valid query for the San Diego 
Harbormaster, while it also restricts the query response by limiting 
Vessel_Classification_Level to the User_Security_Level, and setting the field for 
Vessel_Originating_Port to the User_Role_Location, or in this case San Diego. 


<Rule 

styles" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD Harbormaster query is vaiid origination 2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 
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<Fun 

uri="dc : date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier" /> 

</scope> 

<oid>rule32</oid> 

<!— SD Harbormaster query is valid origination 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</ Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Locat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego"</ Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port Query"</Ind> 
</rhs> 

</Equal> 

</And> 
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<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</ Ru1e > 


Listing 43. RuleML code for RulelD 32 


RulelD 33 is titled Alert Oak TS IB 2. This rule is established as a trigger within the 
ruleset to identify that an Alert Message is present and to verify the level of the Alert 
Message against the security level of the user producing the query. This rule is identical 
in functionality to RulelD 30. This particular rule is used as an extension to our baseline 
seenario to aecount for users at the port of Oakland. This will indieate to the ID and IB 
that an alert is present that pertains to the user query, and that the user is below the alert’s 
classification level. 


<Rule 

style="act ive" 
evaluat ion="strong"> 
<label> 

<Plex> 

<Expr> 
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<Fun 

uri="dc :title"> 

<Ind>Alert OakTS IB 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declass!tier" /> 

</ scope> 

<oid>rule33</oid> 

<!— Alert OakTS IB 2 —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 
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<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster Oakland"</ Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

</do> 

</Rule> 


Listing 44. RuleML code for RulelD 33 

RulelD 34 is titled IB Results 0.1. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Unelassified IB with ID Injection for 
Oakland Alert.” This is done after cheeking the user’s security level and for the presence 
of an alert for this location. The IB, in this case, would return its regular result from the 
Unclassified level IB (since the user is at the Unclassified level), and then the required 
Alert Message insertion from the higher (TS or Seeret) IB. The level of the Alert 
Message is not revealed to the user from the IB. This rule was created to allow for 
Harbormaster queries from the port of Oakland as an extension to the San Diego port 
accounted for in our scenario. 


<Rule 

style="act ive" 
evaluat ion="strong"> 
<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 
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<Ind>IB Results 0.1</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule34</oid> 

<!— IB Results 0.1 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</ Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 
<Var>Subject</Var> 

</Atom> 
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</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of 

Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Sub ject</Var> 

<Ind 

type="string">"Vessel Results from Unclassified IB with ID 
Injection for Oakland Alert"</Ind> 

</Atom> 

</do> 

</Rule> 


Listing 45. RuleML code for RulelD 34 

RulelD 35 is titled IB Results 0.2. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Unclassified IB with ID Injection for San 
Diego Alert.” This is done after checking the user’s security level and for the presence of 
an alert for this location. The IB, in this case, would return its regular result from the 
Unclassified level IB (since the user is at the Unclassified level), and then the required 
Alert Message insertion from the higher (TS or Secret) IB. The level of the Alert 
Message is not revealed to the user from the IB. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB Results 0.2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule35</oid> 

<!— IB Results 0.2 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of San 

Diego"</Ind> 

</rhs> 
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</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Unclassified IB with ID 
injection for San Diego Alert"</ind> 

</Atom> 

</do> 

</Rule> 


Listing 46. RuleML code for RulelD 35 


RulelD 36 is titled IB Results 0.3. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Unclassified IB with ID Injeetion for San 
Diego Alert.” This is done after cheeking the user’s security level and for the presence of 
an alert for this location. The IB, in this case, would return its regular result from the 
Unclassified level IB (since the user is at the Unclassified level), and then the required 
Alert Message insertion from the TS IB. The level of the Alert Message is not revealed to 
the user from the IB. 


<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<ind>iB Results 0.3</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 
<ind>Randy Arvay</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
<ind>3/5/2009</ind> 
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</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</ scope> 

<oid>rule36</oid> 

<!— IB Results 0.3 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</ Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 
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<Ind 

type="string">"Vessel Results from Unclassified IB with ID 
injection for San Diego Alert"</ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 47. RuleML code for RulelD 36 


RulelD 37 is titled No Alert IB. This rule is established as a trigger within the ruleset to 
identify that an Alert Message is not present at a higher level IB. This is provide a 
positive response to a negative search result (i.e., no alert message found). 


<Rule 

style="act ive" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<ind>No Alert iB</ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :date"> 
<ind>3/10/2009</ind> 

</Fun> 

</Fxpr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#inf ormation_Declassifier" /> 
</ scope> 

<oid>rule37</oid> 

<!— No Alert IB —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 
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<rhs> 

<Ind 

type="string">"No Alert Exists"</Ind> 
</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 48. RuleML code for RulelD 37 


RulelD 38 is titled IB Results 2.1. This is one of the ten IB results rules that is intended to 
replicate the results from an actual IB. It is used, based on the variables it is sourced with 
to provide an expected result when testing the rule base with a sample query. In this case, 
it returns the IB result of “Vessel Results from Secret IB and Unclassified IB with ID 
Injection for San Diego Alert.” This is done after checking the user’s security level and 
for the presence of an alert for this location. The IB, in this case, would return its regular 
result from both the Unclassified and Secret level IB’s (since the user is at the Secret 
level), and then the required Alert Message insertion from the TS IB. 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 2.1</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 
<Ind>Randy Arvay</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
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<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rule38</oid> 

<!— IB Results 2.1 —> 

<if> 

<And> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 
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<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Secret IB and 
Unclassified IB with ID Injection for San Diego Alert"</Ind> 
</Atom> 

</do> 

</ Ru1e > 


Listing 49. RuleML code for RulelD 38 


RulelD 39 is titled EWO Query is Invalid. This is a filtering rule and is used to verify that 
the user (EWO) is requesting an allowable query. It verifies the role of the query 
requestor and is intended to provide a positive response to the query check in the case of 
a negative response (i.e., an invalid query request). 


<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>EWO query is invalid</ Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/10/2009</Ind> 

</Fun> 
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</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule39</oid> 

<!— EWO query is invalid —> 

<if> 

<0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic Warfare Off icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"EWO"</Ind> 

</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</ Ru1e > 


Listing 50. RuleML code for RulelD 39 

RulelD 40 is titled HM Query is Invalid. This is a filtering rule and is used to verify that 
the user (Harbormaster) is requesting an allowable query. In this case, it allows for 
Harbormaster queries to originate from San Diego and Oakland only. Any other location 
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for the role of a Harbormaster will make the query invalid. It verifies the role of the query 
requestor and is intended to provide a positive response to the query check in the case of 
a negative response (i.e., an invalid query request). 


<Rule 

style="active" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>HM query is invalid</ Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rule40</oid> 

<!— HM query is invalid —> 

<if> 

<0r> 

<Equal> 

<lhs> 

<Atom> 

< Re1 >U s e r_Ro1e </ Re1 > 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster Oakland"</ lnd> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 
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<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</Ind> 
</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

</Rulebase> 

</RuleML> 


Listing 51. RuleML code for RulelD 40 
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APPENDIX B. RULEML CODE 


<?xml version="l . 0" encoding="ut f-8"?> 

<RuleML xmlns="http ://www.ruleml.org/0.91/xsd"> 

<Rulebase> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>MDA_Scenario_Arvay_current</ Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>12/4/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<!— Rule Policy Information_Declassifier —> 

<!— oid of the rule base / module —> 

<Ind>Inf ormation_Declass!fie r</ Ind> 

<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert Not Valid for Role Locat ion</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 
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52 

53 
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62 
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73 

74 
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76 
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79 

80 

81 
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84 
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99 
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101 
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</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>ruleO</oid> 

<!— Alert Not Valid for Role Location —> 

<if> 

<Or> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert Exists (SECRET IB) for Port of 

Los Angeles"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert Exists (TS IB) for Port of Los 

Angeles"</lnd> 

</rhs> 

</Equal> 

</Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"No Alert Exists"</lnd> 

</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
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107 

108 

109 

110 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 


<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

style="active" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :tit le"> 

<Ind>Alert Notification is Present</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rulel</oid> 

<!— Alert Notification is Present —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="bool">true</lnd> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_lnsert ion</Rel> 
<Var>Subject</Var> 
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176 

177 

178 
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184 

185 

186 

187 
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189 

190 

191 

192 

193 

194 

195 
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197 

198 

199 
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211 

212 

213 

214 

215 

216 


<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title "> 

<Ind>Est Location for Role</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 
</scope> 

<oid>rule2</oid> 

<!— Est Location for Role —> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" String"> "Oakland" </Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Location</Rel> 

<Var>Subject</Var> 
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240 

241 
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244 
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246 

247 
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249 
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</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego" </Ind> 
</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 0</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 
</scope> 

<oid>rule3</oid> 

<!— IB Results 0 —> 

<if> 

<And> 

<And> 

<And> 
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272 

273 

274 

275 

276 

277 

278 

279 

280 

281 

282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 


<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</ Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS iB) for Port of 

Oakiand"</ind> 

</rhs> 

</Equai> 

</And> 

</if> 

<do> 

<Atom> 

<Rei>Return_iB_Resuit s</Rei> 

<Var>Subject</Var> 

<ind 

type="string">"Vessei Resuits from Unciassified iB with iD 
injection for Oakiand Aiert"</ind> 

</Atom> 

</do> 

</ Ruie > 

<Ruie 

sty ie=" active" 
evaiuat ion="strong"> 

<iabei> 

<Piex> 

<Expr> 

<Fun 

uri="dc :titie"> 
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327 

328 

329 

330 
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332 
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334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 


<Ind>Oakland Harbormaster query is valid 
destinat ion</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule4</oid> 

<!— Oakland Harbormaster query is valid destination —> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 
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382 

383 
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385 
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388 

389 

390 
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393 
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395 

396 

397 

398 

399 

400 

401 

402 

403 

404 

405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 

423 

424 

425 

426 

427 

428 

429 

430 

431 

432 

433 

434 

435 

436 


<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port Query" </Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Policy Decision Point</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 
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437 
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439 

440 

441 
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443 

444 

445 

446 

447 

448 

449 

450 

451 

452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 

482 

483 

484 

485 

486 

487 

488 

489 

490 

491 


uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>2 /2 6/2 0 0 9</ Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rule5</oid> 

<!— Policy Decision Point —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Re 1 >Us e r_Ro1e_P e rmi ssions</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="bool">true</ lnd> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

<lnd 

type="bool">true</lnd> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<lnd>Posit ive ID Response to IB for Alert</lnd> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 
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519 

520 

521 

522 

523 

524 

525 

526 

527 

528 

529 

530 

531 

532 

533 

534 

535 

536 

537 

538 

539 

540 

541 

542 

543 

544 

545 

546 


<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>12/5/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rule6</oid> 

<!— Positive ID Response to IB for Alert —> 
<if> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>Query_Requires_Data_Insert ion</Rel> 
<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Query is Valid</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 
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579 
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586 

587 

588 

589 
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591 

592 

593 

594 
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596 
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598 
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600 

601 


<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule7</oid> 

<!— Query is Valid —> 

<if> 

<Or> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert Notification is Absent</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
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602 

603 

604 

605 
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607 

608 
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610 
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613 
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620 

621 

622 

623 

624 
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627 

628 

629 

630 

631 
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641 

642 

643 
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646 

647 

648 

649 

650 

651 

652 

653 

654 

655 

656 


<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 
</scope> 

<oid>rule8</oid> 

<!— Alert Notification is Absent —> 

<if> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_Insertion</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert SD Secret IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 
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657 

658 

659 
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665 
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670 
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691 

692 
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698 

699 

700 

701 

702 

703 

704 

705 

706 

707 

708 

709 
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711 


</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule9</oid> 

<!— Alert SD Secret IB —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of 

San Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassified"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</Ind> 
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712 

713 

714 

715 

716 

111 

718 

719 

720 

721 

722 

723 

724 

725 

726 

727 

728 

729 

730 

731 

732 

733 

734 

735 

736 

737 

738 

739 

740 

741 

742 

743 

744 

745 

746 

747 

748 

749 

750 

751 

752 

753 

754 

755 

756 

757 

758 

759 

760 

761 

762 

763 

764 

765 

766 


</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>EWO query is valid</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 
</scope> 

<oid>rulelO</oid> 

<!— EWO query is valid —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 
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767 

768 

769 

770 

771 

772 

773 

774 

775 

776 

777 

778 

779 

780 

781 

782 

783 

784 

785 

786 

787 

788 

789 

790 

791 

792 

793 

794 

795 

796 

797 

798 

799 

800 

801 

802 

803 

804 

805 

806 

807 

808 

809 

810 

811 

812 

813 

814 

815 

816 

817 

818 

819 

820 

821 


<Ind 

type="string">"EWO"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="st ring"> "Top Secret "</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 
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822 

823 

824 

825 
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827 

828 

829 
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831 

832 

833 

834 
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836 

837 

838 

839 

840 

841 

842 

843 

844 

845 

846 

847 

848 

849 

850 

851 

852 

853 

854 

855 

856 

857 

858 

859 

860 

861 

862 

863 

864 

865 

866 

867 

868 

869 

870 

871 

872 

873 

874 

875 

876 


</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rulell</oid> 

<!— IB Results 2 —> 

<if> 

<And> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of 

Oakland"</Ind> 

</rhs> 
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877 
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917 
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920 
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923 
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925 
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928 
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930 

931 


</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Secret IB and 
Unclassified IB with ID Injection for Oakland Alert"</Ind> 
</Atom> 

</do> 

</ Ru1e > 

<Rule 

sty le=" active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Negat ive ID Response to IB for Alert</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormatIon_Declassifier" /> 

</ scope> 
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932 
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951 

952 

953 

954 

955 

956 

957 

958 

959 

960 
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963 
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967 
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969 

970 
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972 
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<oid>rulel2</oid> 

<!— Negative ID Response to IB for Alert —> 

<if> 

<And> 

<Atom> 

<ReI>VaIid_Query</ReI> 

<Var>Subject</Var> 

</Atom> 

<EquaI> 

<Ihs> 

<Atom> 

<ReI>Query_Requires_Data_Insert ion</ReI> 

<Var>Subject</Var> 

</Atom> 

</Ihs> 

<rhs> 

<Ind 

type="booI">f alse</ Ind> 

</rhs> 

</EquaI> 

</And> 

</if> 

<do> 

<Atom> 

<ReI>IB_Response_Wait</ReI> 

<Var>Subject</Var> 

<Ind 

type="booI">f alse</lnd> 

</Atom> 

</do> 

</ RuIe > 

<RuIe 

sty Ie=" active" 
evaiuat ion="strong"> 

<iabei> 

<Piex> 

<Expr> 

<Fun 

uri="dc :titie"> 

<Ind>Oakiand Harbormaster query is valid destination 

2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 
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1004 

1005 

1006 

1007 

1008 
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1016 
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1018 

1019 

1020 

1021 

1022 

1023 

1024 

1025 

1026 

1027 

1028 

1029 

1030 

1031 

1032 

1033 

1034 

1035 

1036 

1037 
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1039 

1040 
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</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rulel3</oid> 

<!— Oakland Harbormaster query is valid destination 2 —> 
<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster Oakland"</lnd> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Dest ination_Port Query"</ lnd> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<lnd 

type="bool">true</lnd> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<lnd 

type="string">"Oakland"</lnd> 

</Atom> 
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1042 

1043 

1044 

1045 

1046 

1047 

1048 

1049 

1050 

1051 

1052 

1053 

1054 

1055 

1056 

1057 

1058 

1059 

1060 

1061 

1062 

1063 

1064 

1065 

1066 

1067 

1068 

1069 

1070 

1071 

1072 

1073 

1074 

1075 

1076 

1077 

1078 

1079 

1080 

1081 

1082 

1083 

1084 

1085 

1086 

1087 

1088 

1089 

1090 

1091 

1092 

1093 

1094 

1095 

1096 


<Atom> 

<Rel>Vessel_Classification_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Policy Decision Point 2</Ind> 
</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 
</scope> 

<oid>rulel4</oid> 

<!— Policy Decision Point 2 —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Permissions</Rel> 
<Var>Subject</Var> 
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1097 

1098 

1099 

1100 

1101 

1102 

1103 

1104 

1105 

1106 

1107 

1108 

1109 

1110 

1111 

1112 

1113 

1114 

1115 

1116 

1117 

1118 

1119 

1120 

1121 

1122 

1123 

1124 

1125 

1126 

1127 

1128 

1129 

1130 

1131 

1132 

1133 

1134 

1135 

1136 

1137 

1138 

1139 

1140 

1141 

1142 

1143 

1144 

1145 

1146 

1147 

1148 

1149 

1150 

1151 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Query Invalid</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 
</scope> 

<oid>rulel5</oid> 

<!— Query Invalid —> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 
<Var>Subject</Var> 
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1152 

1153 

1154 

1155 

1156 

1157 

1158 

1159 

1160 

1161 

1162 

1163 

1164 

1165 

1166 

1167 

1168 

1169 

1170 

1171 

1172 

1173 

1174 

1175 

1176 

1177 

1178 

1179 

1180 

1181 

1182 

1183 

1184 

1185 

1186 

1187 

1188 

1189 

1190 

1191 

1192 

1193 

1194 

1195 

1196 

1197 

1198 

1199 

1200 

1201 

1202 

1203 

1204 

1205 

1206 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert SD Secret IB 2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 
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1207 

1208 

1209 

1210 

1211 

1212 

1213 

1214 

1215 

1216 

1217 

1218 

1219 

1220 

1221 

1222 

1223 

1224 

1225 

1226 

1227 

1228 

1229 

1230 

1231 

1232 

1233 

1234 

1235 

1236 

1237 

1238 

1239 

1240 

1241 

1242 

1243 

1244 

1245 

1246 

1247 

1248 

1249 

1250 

1251 

1252 

1253 

1254 

1255 

1256 

1257 

1258 

1259 

1260 

1261 


<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rulel6</oid> 

<!— Alert SD Secret IB 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert Exists (SECRET IB) for Port of 

San Diego"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Unclassif ied"</ lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster"</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 
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1262 

1263 

1264 

1265 

1266 

1267 

1268 

1269 

1270 

1271 

1272 

1273 

1274 

1275 

1276 

1277 

1278 

1279 

1280 

1281 

1282 

1283 

1284 

1285 

1286 

1287 

1288 

1289 

1290 

1291 

1292 

1293 

1294 

1295 

1296 

1297 

1298 

1299 

1300 

1301 

1302 

1303 

1304 

1305 

1306 

1307 

1308 

1309 

1310 

1311 

1312 

1313 

1314 

1315 

1316 


</lhs> 

<rhs> 

<Ind 

type="string">"San Diego" </Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 3</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 
<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 
</scope> 

<oid>rulel7</oid> 

<!— IB Results 3 —> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 
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1317 

1318 

1319 

1320 

1321 

1322 

1323 

1324 

1325 

1326 

1327 

1328 

1329 

1330 

1331 

1332 

1333 

1334 

1335 

1336 

1337 

1338 

1339 

1340 

1341 

1342 

1343 

1344 

1345 

1346 

1347 

1348 

1349 

1350 

1351 

1352 

1353 

1354 

1355 

1356 

1357 

1358 

1359 

1360 

1361 

1362 

1363 

1364 

1365 

1366 

1367 

1368 

1369 

1370 

1371 


<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" string">" Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Secret IB and 
Unclassified IB"</Ind> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

styles" active" 
evaluat ion=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Oakland Harbormaster query is valid 
originat ion</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 
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1372 

1373 

1374 

1375 

1376 

1377 

1378 

1379 

1380 

1381 

1382 

1383 

1384 

1385 

1386 

1387 

1388 

1389 

1390 

1391 

1392 

1393 

1394 

1395 

1396 

1397 

1398 

1399 

1400 

1401 

1402 

1403 

1404 

1405 

1406 

1407 

1408 

1409 

1410 

1411 

1412 

1413 

1414 

1415 

1416 

1417 

1418 

1419 

1420 

1421 

1422 

1423 

1424 

1425 

1426 


<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rulel8</oid> 

<!— Oakland Harbormaster query is valid origination —> 
<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster Oakland"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port Query" </Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 
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1427 

1428 

1429 

1430 

1431 

1432 

1433 

1434 

1435 

1436 

1437 

1438 

1439 

1440 

1441 

1442 

1443 

1444 

1445 

1446 

1447 

1448 

1449 

1450 

1451 

1452 

1453 

1454 

1455 

1456 

1457 

1458 

1459 

1460 

1461 

1462 

1463 

1464 

1465 

1466 

1467 

1468 

1469 

1470 

1471 

1472 

1473 

1474 

1475 

1476 

1477 

1478 

1479 

1480 

1481 


<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Ind 

type="st ring"> "Oakland" </Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert SD TS IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 
</scope> 

<oid>rulel9</oid> 

<!— Alert SD TS IB —> 
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1482 

1483 

1484 

1485 

1486 

1487 

1488 

1489 

1490 

1491 

1492 

1493 

1494 

1495 

1496 

1497 

1498 

1499 

1500 

1501 

1502 

1503 

1504 

1505 

1506 

1507 

1508 

1509 

1510 

1511 

1512 

1513 

1514 

1515 

1516 

1517 

1518 

1519 

1520 

1521 

1522 

1523 

1524 

1525 

1526 

1527 

1528 

1529 

1530 

1531 

1532 

1533 

1534 

1535 

1536 


<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 
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1537 

1538 

1539 

1540 

1541 

1542 

1543 

1544 

1545 

1546 

1547 

1548 

1549 

1550 

1551 

1552 

1553 

1554 

1555 

1556 

1557 

1558 

1559 

1560 

1561 

1562 

1563 

1564 

1565 

1566 

1567 

1568 

1569 

1570 

1571 

1572 

1573 

1574 

1575 

1576 

1577 

1578 

1579 

1580 

1581 

1582 

1583 

1584 

1585 

1586 

1587 

1588 

1589 

1590 

1591 


<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title "> 

<Ind>EWO query is valid 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule20</oid> 

<!— EWO query is valid 2 —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic Warfare Off icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 
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1592 

1593 

1594 

1595 

1596 

1597 

1598 

1599 

1600 

1601 

1602 

1603 

1604 

1605 

1606 

1607 

1608 

1609 

1610 

1611 

1612 

1613 

1614 

1615 

1616 

1617 

1618 

1619 

1620 

1621 

1622 

1623 

1624 

1625 

1626 

1627 

1628 

1629 

1630 

1631 

1632 

1633 

1634 

1635 

1636 

1637 

1638 

1639 

1640 

1641 

1642 

1643 

1644 

1645 

1646 


</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 4</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 
</scope> 

<oid>rule21</oid> 

<!— IB Results 4 —> 
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1647 

1648 

1649 

1650 

1651 

1652 

1653 

1654 

1655 

1656 

1657 

1658 

1659 

1660 

1661 

1662 

1663 

1664 

1665 

1666 

1667 

1668 

1669 

1670 

1671 

1672 

1673 

1674 

1675 

1676 

1677 

1678 

1679 

1680 

1681 

1682 

1683 

1684 

1685 

1686 

1687 

1688 

1689 

1690 

1691 

1692 

1693 

1694 

1695 

1696 

1697 

1698 

1699 

1700 

1701 


<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Unclassified IB"</Ind> 
</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Oakland Harbormaster query is valid origination 

2</Ind> 

</Fun> 

</Expr> 
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1702 

1703 

1704 

1705 

1706 

1707 

1708 

1709 

1710 

1711 

1712 

1713 

1714 

1715 

1716 

1717 

1718 

1719 

1720 

1721 

1722 

1723 

1724 

1725 

1726 

1727 

1728 

1729 

1730 

1731 

1732 

1733 

1734 

1735 

1736 

1737 

1738 

1739 

1740 

1741 

1742 

1743 

1744 

1745 

1746 

1747 

1748 

1749 

1750 

1751 

1752 

1753 

1754 

1755 

1756 


<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule22</oid> 

<!— Oakland Harbormaster query is valid origination 2 —> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" String"> "Oakland" </Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 
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1757 

1758 

1759 

1760 

1761 

1762 

1763 

1764 

1765 

1766 

1767 

1768 

1769 

1770 

1771 

1772 

1773 

1774 

1775 

1776 

1777 

1778 

1779 

1780 

1781 

1782 

1783 

1784 

1785 

1786 

1787 

1788 

1789 

1790 

1791 

1792 

1793 

1794 

1795 

1796 

1797 

1798 

1799 

1800 

1801 

1802 

1803 

1804 

1805 

1806 

1807 

1808 

1809 

1810 

1811 


</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port Query" </Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert SD TS IB 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 
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1812 

1813 

1814 

1815 

1816 

1817 

1818 

1819 

1820 

1821 

1822 

1823 

1824 

1825 

1826 

1827 

1828 

1829 

1830 

1831 

1832 

1833 

1834 

1835 

1836 

1837 

1838 

1839 

1840 

1841 

1842 

1843 

1844 

1845 

1846 

1847 

1848 

1849 

1850 

1851 

1852 

1853 

1854 

1855 

1856 

1857 

1858 

1859 

1860 

1861 

1862 

1863 

1864 

1865 

1866 


<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule23</oid> 

<!— Alert SD TS IB 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 
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1867 

1868 

1869 

1870 

1871 

1872 

1873 

1874 

1875 

1876 

1877 

1878 

1879 

1880 

1881 

1882 

1883 

1884 

1885 

1886 

1887 

1888 

1889 

1890 

1891 

1892 

1893 

1894 

1895 

1896 

1897 

1898 

1899 

1900 

1901 

1902 

1903 

1904 

1905 

1906 

1907 

1908 

1909 

1910 

1911 

1912 

1913 

1914 

1915 

1916 

1917 

1918 

1919 

1920 

1921 


</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="act ive" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 5</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</ scope> 

<oid>rule24</oid> 


251 


1922 

1923 

1924 

1925 

1926 

1927 

1928 

1929 

1930 

1931 

1932 

1933 

1934 

1935 

1936 

1937 

1938 

1939 

1940 

1941 

1942 

1943 

1944 

1945 

1946 

1947 

1948 

1949 

1950 

1951 

1952 

1953 

1954 

1955 

1956 

1957 

1958 

1959 

1960 

1961 

1962 

1963 

1964 

1965 

1966 

1967 

1968 

1969 

1970 

1971 

1972 

1973 

1974 

1975 

1976 


<!— IB Results 5 —> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from TS IB^ Secret IB, and 
Unclassified IB"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>SD Harbormaster query is valid destinat ion</Ind> 
</Fun> 
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1977 

1978 

1979 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

1991 

1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

2002 

2003 

2004 

2005 

2006 

2007 

2008 

2009 

2010 

2011 

2012 

2013 

2014 

2015 

2016 

2017 

2018 

2019 

2020 

2021 

2022 

2023 

2024 

2025 

2026 

2027 

2028 

2029 

2030 

2031 


</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule25</oid> 

<!— SD Harbormaster query is valid destination —> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego" </Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 
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2032 

2033 

2034 

2035 

2036 

2037 

2038 

2039 

2040 

2041 

2042 

2043 

2044 

2045 

2046 

2047 

2048 

2049 

2050 

2051 

2052 

2053 

2054 

2055 

2056 

2057 

2058 

2059 

2060 

2061 

2062 

2063 

2064 

2065 

2066 

2067 

2068 

2069 

2070 

2071 

2072 

2073 

2074 

2075 

2076 

2077 

2078 

2079 

2080 

2081 

2082 

2083 

2084 

2085 

2086 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port Query" </Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert Oak Secret IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 
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2087 

2088 

2089 

2090 

2091 

2092 

2093 

2094 

2095 

2096 

2097 

2098 

2099 

2100 

2101 

2102 

2103 

2104 

2105 

2106 

2107 

2108 

2109 

2110 

2111 

2112 

2113 

2114 

2115 

2116 

2117 

2118 

2119 

2120 

2121 

2122 

2123 

2124 

2125 

2126 

2127 

2128 

2129 

2130 

2131 

2132 

2133 

2134 

2135 

2136 

2137 

2138 

2139 

2140 

2141 


</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule26</oid> 

<!— Alert Oak Secret IB —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string"> "Harbormaster Oakland" </Ind> 

</rhs> 
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2142 

2143 

2144 

2145 

2146 

2147 

2148 

2149 

2150 

2151 

2152 

2153 

2154 

2155 

2156 

2157 

2158 

2159 

2160 

2161 

2162 

2163 

2164 

2165 

2166 

2167 

2168 

2169 

2170 

2171 

2172 

2173 

2174 

2175 

2176 

2177 

2178 

2179 

2180 

2181 

2182 

2183 

2184 

2185 

2186 

2187 

2188 

2189 

2190 

2191 

2192 

2193 

2194 

2195 

2196 


</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

sty le=" active" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<ind>iB Resuits 6</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<ind>3/5/2 0 0 9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassifier" /> 
</scope> 

<oid>ruie27</oid> 

<!— iB Resuits 6 —> 

<if> 

<Equai> 

<ihs> 

<Atom> 

<Rei>Vaiid_Query</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="booi">f aise</ind> 

</rhs> 
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2197 

2198 

2199 

2200 

2201 

2202 

2203 

2204 

2205 

2206 

2207 

2208 

2209 

2210 

2211 

2212 

2213 

2214 

2215 

2216 

2217 

2218 

2219 

2220 

2221 

2222 

2223 

2224 

2225 

2226 

2227 

2228 

2229 

2230 

2231 

2232 

2233 

2234 

2235 

2236 

2237 

2238 

2239 

2240 

2241 

2242 

2243 

2244 

2245 

2246 

2247 

2248 

2249 

2250 

2251 


</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Result s</Rel> 

<Var>Subject</Var> 

<Ind 

type="st ring" >" Invalid Query! "</ Ind> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

style="active" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>SD Harbormaster query is valid destination 2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</ scope> 

<oid>rule28</oid> 

<!— SD Harbormaster query is valid destination 2 —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

< Re1 >U s e r_Ro1e </ Re1 > 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</Ind> 
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2252 

2253 

2254 

2255 

2256 

2257 

2258 

2259 

2260 

2261 

2262 

2263 

2264 

2265 

2266 

2267 

2268 

2269 

2270 

2271 

2272 

2273 

2274 

2275 

2276 

2277 

2278 

2279 

2280 

2281 

2282 

2283 

2284 

2285 

2286 

2287 

2288 

2289 

2290 

2291 

2292 

2293 

2294 

2295 

2296 

2297 

2298 

2299 

2300 

2301 

2302 

2303 

2304 

2305 

2306 


</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Ind 

type="st ring"> "San Diego" </Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 
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2307 

2308 

2309 

2310 

2311 

2312 

2313 

2314 

2315 

2316 

2317 

2318 

2319 

2320 

2321 

2322 

2323 

2324 

2325 

2326 

2327 

2328 

2329 

2330 

2331 

2332 

2333 

2334 

2335 

2336 

2337 

2338 

2339 

2340 

2341 

2342 

2343 

2344 

2345 

2346 

2347 

2348 

2349 

2350 

2351 

2352 

2353 

2354 

2355 

2356 

2357 

2358 

2359 

2360 

2361 


<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title "> 

<Ind>Alert Oak Secret IB 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule29</oid> 

<!— Alert Oak Secret IB 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of 

Oakland" </Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 


259 


2362 

2363 

2364 

2365 

2366 

2367 

2368 

2369 

2370 

2371 

2372 

2373 

2374 

2375 

2376 

2377 

2378 

2379 

2380 

2381 

2382 

2383 

2384 

2385 

2386 

2387 

2388 

2389 

2390 

2391 

2392 

2393 

2394 

2395 

2396 

2397 

2398 

2399 

2400 

2401 

2402 

2403 

2404 

2405 

2406 

2407 

2408 

2409 

2410 

2411 

2412 

2413 

2414 

2415 

2416 


</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" String"> "Oakland" </Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>SD Harbormaster query is valid origination</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 
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2417 

2418 

2419 

2420 

2421 

2422 

2423 

2424 

2425 

2426 

2427 

2428 

2429 

2430 

2431 

2432 

2433 

2434 

2435 

2436 

2437 

2438 

2439 

2440 

2441 

2442 

2443 

2444 

2445 

2446 

2447 

2448 

2449 

2450 

2451 

2452 

2453 

2454 

2455 

2456 

2457 

2458 

2459 

2460 

2461 

2462 

2463 

2464 

2465 

2466 

2467 

2468 

2469 

2470 

2471 


</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule30</oid> 

<!— SD Harbormaster query is valid origination —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port Query" </Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 
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2472 

2473 

2474 

2475 

2476 

2477 

2478 

2479 

2480 

2481 

2482 

2483 

2484 

2485 

2486 

2487 

2488 

2489 

2490 

2491 

2492 

2493 

2494 

2495 

2496 

2497 

2498 

2499 

2500 

2501 

2502 

2503 

2504 

2505 

2506 

2507 

2508 

2509 

2510 

2511 

2512 

2513 

2514 

2515 

2516 

2517 

2518 

2519 

2520 

2521 

2522 

2523 

2524 

2525 

2526 


</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"San Diego"</Ind> 
</Atom> 

<Atom> 

<Rel>Vessel_Classif icat ion_Level</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Subject</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="act ive" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>Alert OakTS IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</ scope> 

<oid>rule31</oid> 
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2527 

2528 

2529 

2530 

2531 

2532 

2533 

2534 

2535 

2536 

2537 

2538 

2539 

2540 

2541 

2542 

2543 

2544 

2545 

2546 

2547 

2548 

2549 

2550 

2551 

2552 

2553 

2554 

2555 

2556 

2557 

2558 

2559 

2560 

2561 

2562 

2563 

2564 

2565 

2566 

2567 

2568 

2569 

2570 

2571 

2572 

2573 

2574 

2575 

2576 

2577 

2578 

2579 

2580 

2581 


<!— Alert OakTS IB —> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="st ring"> "Top Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="st ring"> "Oakland" </Ind> 

</rhs> 
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2582 

2583 

2584 

2585 

2586 

2587 

2588 

2589 

2590 

2591 

2592 

2593 

2594 

2595 

2596 

2597 

2598 

2599 

2600 

2601 

2602 

2603 

2604 

2605 

2606 

2607 

2608 

2609 

2610 

2611 

2612 

2613 

2614 

2615 

2616 

2617 

2618 

2619 

2620 

2621 

2622 

2623 

2624 

2625 

2626 

2627 

2628 

2629 

2630 

2631 

2632 

2633 

2634 

2635 

2636 


</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</ Ind> 

</Atom> 

</do> 

</ Ru1e > 

<Rule 

sty le=" active" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<ind>SD Harbormaster query is vaiid origination 2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<ind>3/5/2 0 0 9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassifier" /> 

</scope> 

<oid>ruie32</oid> 

<!— SD Harbormaster query is vaiid origination 2 —> 

<if> 

<And> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Subject</Var> 

</Atom> 

</ihs> 

<rhs> 
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2637 

2638 

2639 

2640 

2641 

2642 

2643 

2644 

2645 

2646 

2647 

2648 

2649 

2650 

2651 

2652 

2653 

2654 

2655 

2656 

2657 

2658 

2659 

2660 

2661 

2662 

2663 

2664 

2665 

2666 

2667 

2668 

2669 

2670 

2671 

2672 

2673 

2674 

2675 

2676 

2677 

2678 

2679 

2680 

2681 

2682 

2683 

2684 

2685 

2686 

2687 

2688 

2689 

2690 

2691 


<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="st ring"> "San Diego" </Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classification_Level</Rel> 

<Var>Subject</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Subject</Var> 

<Atom> 
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2692 

2693 

2694 

2695 

2696 

2697 

2698 

2699 

2700 

2701 

2702 

2703 

2704 

2705 

2706 

2707 

2708 

2709 

2710 

2711 

2712 

2713 

2714 

2715 

2716 

2717 

2718 

2719 

2720 

2721 

2722 

2723 

2724 

2725 

2726 

2727 

2728 

2729 

2730 

2731 

2732 

2733 

2734 

2735 

2736 

2737 

2738 

2739 

2740 

2741 

2742 

2743 

2744 

2745 

2746 


<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title "> 

<Ind>Alert OakTS IB 2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule33</ oid> 

<!— Alert OakTS IB 2 —> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of 

Oakland" </Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 
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2747 

2748 

2749 

2750 

2751 

2752 

2753 

2754 

2755 

2756 

2757 

2758 

2759 

2760 

2761 

2762 

2763 

2764 

2765 

2766 

2767 

2768 

2769 

2770 

2771 

2772 

2773 

2774 

2775 

2776 

2777 

2778 

2779 

2780 

2781 

2782 

2783 

2784 

2785 

2786 

2787 

2788 

2789 

2790 

2791 

2792 

2793 

2794 

2795 

2796 

2797 

2798 

2799 

2800 

2801 


<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster Oakland"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 0.1</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 
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2802 

2803 

2804 

2805 

2806 

2807 

2808 

2809 

2810 

2811 

2812 

2813 

2814 

2815 

2816 

2817 

2818 

2819 

2820 

2821 

2822 

2823 

2824 

2825 

2826 

2827 

2828 

2829 

2830 

2831 

2832 

2833 

2834 

2835 

2836 

2837 

2838 

2839 

2840 

2841 

2842 

2843 

2844 

2845 

2846 

2847 

2848 

2849 

2850 

2851 

2852 

2853 

2854 

2855 

2856 


</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule34</oid> 

<!— IB Results 0.1 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassified"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of 

Oakland" </Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Subject</Var> 
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2857 

2858 

2859 

2860 

2861 

2862 

2863 

2864 

2865 

2866 

2867 

2868 

2869 

2870 

2871 

2872 

2873 

2874 

2875 

2876 

2877 

2878 

2879 

2880 

2881 

2882 

2883 

2884 

2885 

2886 

2887 

2888 

2889 

2890 

2891 

2892 

2893 

2894 

2895 

2896 

2897 

2898 

2899 

2900 

2901 

2902 

2903 

2904 

2905 

2906 

2907 

2908 

2909 

2910 

2911 


<Ind 

type="string">"Vessel Results from Unclassified IB with ID 
Injection for Oakland Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title "> 

<Ind>IB Results 0.2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule35</ oid> 

<!— IB Results 0.2 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 
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2912 

2913 

2914 

2915 

2916 

2917 

2918 

2919 

2920 

2921 

2922 

2923 

2924 

2925 

2926 

2927 

2928 

2929 

2930 

2931 

2932 

2933 

2934 

2935 

2936 

2937 

2938 

2939 

2940 

2941 

2942 

2943 

2944 

2945 

2946 

2947 

2948 

2949 

2950 

2951 

2952 

2953 

2954 

2955 

2956 

2957 

2958 

2959 

2960 

2961 

2962 

2963 

2964 

2965 

2966 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassified"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (SECRET IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Unclassified IB with ID 
Injection for San Diego Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>IB Results 0.3</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2009</Ind> 

</Fun> 


270 


2967 

2968 

2969 

2970 

2971 

2972 

2973 

2974 

2975 

2976 

2977 

2978 

2979 

2980 

2981 

2982 

2983 

2984 

2985 

2986 

2987 

2988 

2989 

2990 

2991 

2992 

2993 

2994 

2995 

2996 

2997 

2998 

2999 

3000 

3001 

3002 

3003 

3004 

3005 

3006 

3007 

3008 

3009 

3010 

3011 

3012 

3013 

3014 

3015 

3016 

3017 

3018 

3019 

3020 

3021 


</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule36</oid> 

<!— IB Results 0.3 —> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Subject</Var> 

<Ind 
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3022 

3023 

3024 

3025 

3026 

3027 

3028 

3029 

3030 

3031 

3032 

3033 

3034 

3035 

3036 

3037 

3038 

3039 

3040 

3041 

3042 

3043 

3044 

3045 

3046 

3047 

3048 

3049 

3050 

3051 

3052 

3053 

3054 

3055 

3056 

3057 

3058 

3059 

3060 

3061 

3062 

3063 

3064 

3065 

3066 

3067 

3068 

3069 

3070 

3071 

3072 

3073 

3074 

3075 

3076 


type="string">"Vessel Results from Unclassified IB with ID 
injection for San Diego Alert"</ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="act ive" 
evaluation=" strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<ind>No Alert iB</ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri=="dc : author"> 

<ind>Randy Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<ind>3/10/2009</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#information_Declassifier" /> 

</ scope> 

<oid>rule37</oid> 

<!— No Alert IB —> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Not ificat ion</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"No Alert Exists"</ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Subject</Var> 

<ind 
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3077 

3078 

3079 

3080 

3081 

3082 

3083 

3084 

3085 

3086 

3087 

3088 

3089 

3090 

3091 

3092 

3093 

3094 

3095 

3096 

3097 

3098 

3099 

3100 

3101 

3102 

3103 

3104 

3105 

3106 

3107 

3108 

3109 

3110 

3111 

3112 

3113 

3114 

3115 

3116 

3117 

3118 

3119 

3120 

3121 

3122 

3123 

3124 

3125 

3126 

3127 

3128 

3129 

3130 

3131 


type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="act ive" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB Results 2.1</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :date"> 

<Ind>3/5/2 0 0 9</Ind> 

</Fun> 

</Fxpr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</ scope> 

<oid>rule38</oid> 

<!— IB Results 2.1 —> 

<if> 

<And> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Subject</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 
<Var>Subject</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Subject</Var> 

</Atom> 
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3132 

3133 

3134 

3135 

3136 

3137 

3138 

3139 

3140 

3141 

3142 

3143 

3144 

3145 

3146 

3147 

3148 

3149 

3150 

3151 

3152 

3153 

3154 

3155 

3156 

3157 

3158 

3159 

3160 

3161 

3162 

3163 

3164 

3165 

3166 

3167 

3168 

3169 

3170 

3171 

3172 

3173 

3174 

3175 

3176 

3177 

3178 

3179 

3180 

3181 

3182 

3183 

3184 

3185 

3186 


</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notification</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert Exists (TS IB) for Port of San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San Diego" </Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Subject</Var> 

<Ind 

type="string">"Vessel Results from Secret IB and 
Unclassified IB with ID Injection for San Diego Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>EWO query is invalid</Ind> 

</Fun> 
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3227 

3228 

3229 

3230 

3231 

3232 

3233 

3234 

3235 

3236 

3237 

3238 

3239 

3240 

3241 


</Expr> 

<Expr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc :date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Information_Declassifier" /> 

</scope> 

<oid>rule39</oid> 

<!— EWO query is invalid —> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic Warfare Off icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="st ring"> "EWO" </Ind> 

</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 
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</Atom> 

</do> 

</Rule> 

<Rule 

style="active" 
evaluat ion="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc :title"> 

<Ind>HM query is invalid</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :author"> 

<Ind>Randy Arvay</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc :date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Fxpr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassifier" /> 

</scope> 

<oid>rule40</oid> 

<!— HM query is invalid —> 

<if> 

<Or> 

<Fqual> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster Oakland"</Ind> 
</rhs> 

</Fqual> 

<Fqual> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Subject</Var> 

</Atom> 

</lhs> 
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<rhs> 

<Ind 

type="string">"Harbormaster San Diego"</Ind> 
</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Subject</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

</Rulebase> 

</RuleML> 
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APPENDIX C. RULE TRACE OE USE CASE SUPPORTED 


The visual trace of the ruleset execution to show support for the system’s intended 

use. This trace is completed using the following parameters: 

Type of query: Destination Port 

Role / Actor: Harbormaster 

Location: San Diego 

Security Level: Lfnclassified 

Alert Present: False 

Alert Classification Level: Not Applicable 

Expected Result: “Vessel Results from Unclassified IB” 


The expected result from this query and the RuleML execution is an IB response of 
“Vessel Results from Unclassified IB” to the user. The trace was completed using 
RuleManager’s Interactive Rule Map functionality. The pop-up boxes shown throughout 
the trace indicate the sourcing of predicates that would be included with tagged data in a 
live system. This was not replicated for this research and instead was manually inserted 
via the dialog boxes. 

For the rule trace shown and from the interactive rule map of RuleManager, 
various indicators are used to show the actions during the trace. A rule or variable 
highlighted in Yellow, indicates that a rule or variable is currently being sourced. A rule 
depicted in Red indicates that the rule did not fire (execute) from the ruleset. A rule 
shown highlighted in Green indicates that the rule did fire and the result of that firing is 
also shown in the green highlighted box with the predicate name. Pop-up dialog boxes 
shown in the trace indicate the sourcing of a variable or predicate that would be done by 
an external entity (service) or taken from XML attributes attached to the query upon 
origination (i.e., user role and user security level). 
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Results 0 

^yiBRKvItsOJ 




_J Alert MotifKatian b Absem 



It Rule 'Quecy b Valid' b in progress, [click on 

that Bashing thing Id conCinuej 
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TAtet«tiv*JUil*Map 
Kale Q 


^ labet 


^Negative 3D Re£|wniet&]B fcr Alert 
I^Qucyii Vai^ ^ [$ B«ulti 04 


i^B Results 24 


- V^,Qii«r 

Tvs 


^pDiitm! ID Mj4Qtiwliwj|icl] rt 


^ B Rcfulti □ J 

^:BflesultsCl 41l IB RKultf 04 

^ Alert MotifKatian ia Absent 




Rule 'Query ii Valid' fired, [click on that flashing thing to continue] 


Tntet«tiv*Rul*Msp 
Kale ■-Q- 


O: 


jsi Megat^e ID Respcnse to IS for Alert 

^IB Results 2 

-J E Results i _ 3 j IE 04 


^ Rosieivc ID Response to ]B for Alert 


4:136 Remits 04 


Jl IB Results 03 




Term lB_RespDnse_Wart' Sourced, [dick on that ffashing thing to continue] 
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Kale ij 


^labet 


0 






^Afetl NotfTicaliQn ii PrsenE 


^ N^altive ID Responie to IB for Alert 1 


U PiKitivelD Re$p^nfeto IB f«r Alert 


Alert hlotificetion rt AbicnE 




Term 'Query^RHttiines_DatBjn£erti{>n' Sauced, [flick on that flashing thing tJi continue] 


Tntet«tiv*Rul*Msp 
Kale ■-Q- 


O: 


^ Alert OakT^eZ 
Alert Oflk S«<re$JS 


JSl Afert SD T5 IB. ^ Alt^ SO Secre* I& 


Alert Oak ^nct 16 2 


^ Alert Notification is Present I for Role Lof ation 


;^AIert SO Secret IB Z 




Term 'Aleft,Pfiesent_RespDns<' Sourced, [click on thart fiashing thing to continue] 
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TAtet«tiv*JUil*Map 
Kale Q 


^ labet 


IlJAIertOakT5]B2 


RauPlsQJ 

zJ Alert Dak Secret IE 2 


^ AkTt_rtotifkxt{Dn 


Oil Alert SO Secret IB 




ZU Alert hot Valid for Role Location 


^AJeitSOTSlB^ 


^IB Results 2 

^ Alert SD Secret IB 2 


^ Alert OakTS jj Oah Secret IB 

^ IB Results 0^ 




Term 'Alert^NertrRcatron' Sourced, [click on that Hashing thmg to continue] 


Tfttet«tivOltul*Map 
Kale ■-Q- 


O: 


liJAIertOakTSIBJ 


^ Be Results QJ 
^ Alert Dak Secret IE 2 


ZU Alert hot Valid for Role Location 


% Alert_rfatifkx^ 


^ Alert SO Secret IB 


^ Alert SOTS IB 2 


IB Risults 2 

^AJertSDSecretlB2 


Alert OakTS ^ ^^t Oak Secret IB 

^IB Results 0^ 
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Kale Q- 

T‘ 

I 


^labet 


0 


:ilAJertOakT5]0.I 





Trttet«tiv*H«l*Map 
Kale ■-Q— 


4>; 


^ AleA NetilkatJan Es Presenl 


^AJcrt OalcTSIB2 


^ Akrt Oait Sctrrt ]& 2 
AJeA Mot Valie^ fcr Role LocatiDn 


:2lAI»tS0TSIB2 


! ^ Alat MrtjTiEation a flbsertt | 


' Meat Rriseiri_R«p«w 
Feift 


Al«t SD Secret IS 2 


j^AltAOtk SacratlS 


jI^AJartSOTSIB 


Alert SDS&cwt IB 


31 Alert OiltTSie 




Term 'Aleit^Notrficalfon' ScrijncecL [click on that fla&tiiingthmg to continue] 
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Kale Q- 


O 


^labet 


0 


^ AleA Netilkaftian Es Present 


^ Alert 0akTSiB2 


^ Alert Oeh Secret IS 1 
i^AJeit Mot Valid for RdIc LocatiDn 


jafAlertSOTSIB^ 


I^AIertN ot iftcation is A3?ientl 


' Alert (Yesent Response 

me 


^ Alert SD Secret ffi 2 


IjJiNoAiemBi 


Alert Oak Secret IS 


JU Alert SOTS IB 




^AlertSDS&ecetlB 

Alert 04ltTS 10 




Rule'MD Alert IB'fired, [click on that flashing thin^ Do continue] 


Tnteraetivie Rule Map 
Kale ■-Q- 


T: 


^ Alert Netilkatian is Present 


I^AIertQakTSIBZl 


^ Alert Oak Secret IS 1 
^ Alert Hrjt Valid for Role Locatjoni 


::3lAlertSOTSIB2 


1 Alert Mrtjfication a Absent [ 


' Alert Prieseiri_Respoiw 

me 


Alert SD Secret IS 2 


1:^ Wo Alert Bi 


Alert Oek Secret IS 


Alert SOTS IB 


Alert SDS«ret IB 


Alert 04kTS 10 




Rule 'Alert OalcTS IB 2' did not Fire, [click on that flashing thing to ccmtiiniue[ 
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Kale Q- 

ii»| 

I 


^labet 


J AleH Netilkaftian Es PresenI 


I^AIcrt&ikTSiBZl 


^ Alert Oeh Secret IS 2 
i^AlErt MdE Valid for RdIc LocatiDn 


::afAI»tSDTSIEI2 


i ^ Alert Notiftc ation g AJasertl 


' Atert_Praent_RespDnse 


^ Alert SD Secret IS 2 


IjJNoAiertIBi 


^ Alert Oak Secret IB 


JIU Alert SOTS IB 




:2JAJertSDS«eetIB 

1^ Alert OalcTSPl 


9 


Rute ‘Alert OakTS IB‘ did FMrt (ma. [click on that flashing thir^g to contmue^ 


Tntet«tivieRul*Map 
Kale ■-Q— 


4>; 


^ Alert Netilkotian Es Present 


I^AIertQakTSIBZl 


IjUAkrtOait Secret IB 21 

Alert Hrjt Valid for Role LocatiDn 


:2fAlertS0TSIB2 


! ^ Alat MrtifiEdtion a Absertt | 


' Alert Praeiri_Resp«w 


Alert SD Secret IS 2 


1:21 Wo Alert IBl 


Alert Oek Secret IB 


Alert SOTS IB 


:2i Alert SDSueet IB 


I-IJ Alert Oakfs^ 




Rule'Alert Oak Secret EB 2 ' did not fire [click on that flashing thing to conlinuei 
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Kale Q 

ii»| 

I 

i ^ Alert Notiftc ation g flJasertl 

" Alert Prsent Response 
fate _ 

Aleit SD Secret IS 2 [ tiIMb AMIFI 


^labet 


^ Alert Net ilk aftj an Es Presenl 


I^AIert&ikTSiBZl 


I -lAtetOefcStCfd]B2l 

Alert Hot Valid for Rale Lacatipn 


I^AkrtOifcSecftllBl 


JIU Alert SOTS IB 


:2JAJertSDS«cetIB 

l-IjAlBt 0 ale 7 s¥l 


9 


Rute‘Alert Oalc Secret EB' did net Fire, fclkk on Chat flashing thmg to cnntinoe] 




IntetKtiv* Rule Map 
Kale ■-Q— 


4>; 


^ Alert Netilkaftian Es Present 


I^AIeitQakTSIBZl 


ljUAkrtOait Secret IB 21 

Alert Hot Valid for Role LacatiDrii 


IjJAtotSOTSBZl 


! ^ Alat Mrtificdtion a Absertt [ 


' Alert Preseiri_RespDiw 

fate 


Alert SD Secret IS 2 


1:^ Wo Alert Bl 


IjJAkrtOaltSecfrtlBl 


Alert SOTS IB 


,2JAJertSDS«wtIB 


I-IJ Alert OiIcTSbI 




Rule'Alert SDISIB 2' did not fire, (click on thalflastiiing thing to cantjnu«] 
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Kale Q- 

ii»| 

I 


^labet 


0 


^ Alen Netilkaftian Es PresenI 


I^AIcrt&ikTSiBZl 


I-IAl^QuitStCfd]B 2 l 

i^AlEft MdE Valid fcr RdI 4 Lacatipn 




i ^ Alert Notiftc ation g flJasertl 


' Atert_Praent_RespDnse 


^ Aleit SD Secret IS i 


IjJNoAiertIBi 


I^AkrtOifcSecftllBl 


Ijj Alert SO TSBl 


: 2 JAJertSDS«cetIB 


l-:j Alert OaleTS^ 




9 


Rule ‘Alert SDIS^ IB' did rwt frf&. [cNch on that flashing Ihin^ to conefivue|| 


Trttet«tivieRul*Map 
Kale ■-Q- 




^ Alert Netilkatian Es Present 


Ej Alert QikTsiBlI 

1 ^ Alat MrtifiEdtion a Absertt [ 

1^ Alert SO Secret Bi| 


ljUAkrtOait Secret IB 21 

Alert Mot Valid for Role Locatiorii 


Alert 50 TSBZl 


' Alert Praeiri_RespDiw 
Feift 


Ij^NoAlertlBl 


IjJAkrtOakSecretlBl 


[jJ Alert SO 


^Alert SO Secret IB 


I-:J Alert OafcfsBl 


Rule 'Alert SD Secret IB 2' did not fire, {click on that flashingi thing to continue] 
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Kale Q 

ii»| 

I 

EjAIgtSQTSCzl 

I ^ Alert Notiftc Jtion g AbieHtl 

" Alert Prsent Response 
f9l» 

IjJ No Alert E l 


^labet 


^ Alert Net ilk aftj an Es Presenl 


I^AIertSakTSiBZl 


I-IAl^Pelt Secret]B2l 

Alert Not Valid for Role Lacatipn 


I^AkrtOifcSecfetlBl 

I^AJert OaleTS^ 


[JJ Alert 50 

IjLlAfeftSOSecretBl 


9 


Rute ‘Alert SD Secreit IB' did not fire:, [ditk an that Hashing thin^ Do centlriue^ 




Tntet«tiv*Ryl*Msp 
Kale ■-Q— 


4>; 


^ Alert Netilkatian is Present 


,- . IjjAkrtOtii Secret ]B2l 


IjJAIeitSOTSPZl 


1 ^ Alat HrtifiEdtion a Absertt | 

1 ^ Afert SO Secret BJ| 


' Alert Preseiri_RespDnse 
Feift 


Ij^NoAlertPl 


IjJAkrtOlfcSecretIBl 


IjJ Alert SO TSBl 


I-:J Alert Oifcfs^ 


1^ Aim SO Secret b[ 




Rule'Alert Not VtaFiid For Role location' fired. Eclick on that Bashing thing to continue] 
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Kale Q- 


^labet 


0 


^ Alcft Motificetiwi is Present 


.13,1 Altrt HotificflliQn ii Abjcfitl 


Megjtivg ID Raponw tfl IB lof fllert | 


' Qu«y_Reqiiir«_Data_tn»ftnii 




1^ Poiilive ED Response to EB fw Alert 


9 


Rulie‘Alert Not Valid Far Role Iocetion' fired, (clkk on that flashing thing to continue] 


Tntet«tiv*fUil*Map 
Kale ■-Q— 






AlEft Motificetion rs Present 


I^AJert MfltificBtionHAIwentI 


Megjtrve ID Rappnge tn IB for Alert | 


" (^Hifyjteqdm_{>»tajiiiertk] 


Poitlive ED Respoirse to EB for Alert 




Rule'Alert Notificalnn fi Absent' fired, [dick on that flashing thiivg to continue! 
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Kale Q- 


^labet 


G 


I jJ Akit Motific*ti<m it Prtttn^ 




zj JMtrt HotSicgtion h Alwent I 


Megjtivg ID Raponw tfl IB f Pf fllert | 


' Qu«y_R«qiiir«_Data_tn»ftnii 


1 ^ Poiilive ED Response tc EB fw Alert 


9 


Rute‘Alert Notificalnn 45 Present' did not Fire, fclkk on that Rashin^ thing to crmtinue] 


Tntet«tiv*Rul*Map 
Kale ■-Q— 


4>; 




:^BKe^n\ 


:3J PnsitivftID Respnnieto 3B for Alert etoffi fwAJ^ 


' 1B,(tDpoiisc_Wa(t 


.:JIB ReuiltsOJ 


Jje Results OJ 


ResulbO.2 




Rule'Alert Notifieelnn is Present' did not Fire, (click on that Hashing thmg tn ctmtinue] 
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Kale Q- 


^labet 


0 


-:yiBitc^_24] 


:3J PwitivelD RMpMnffttQ 3B it,t Alert e»« B ftw ATert | 


V IS RespoiHC 


^IBReuiltsO^ 






IRi 


9 


RyPe ID Response to B for Alecf Fired, [click on that fieshinig thin 9 to continue] 


Tntet«tiv*Rul*Map 




:^BKe^n\ 


jaJ Pwitiwft ID I-J ffegatiw ID fl^ponse IM B fof Afart I 


' 1B,nES|»iiic„Wa(t 


^ IB Results OJ 




j2JiSR«$ulbO.Z 




Rute'Megalne ID Response to IB lor AleflT fired, [click on that flashing thing to continue] 
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Kale Q- 


^labet 


0 


-:yiBitc^_24] 


V ^ 


[ - 1 PiK^jy^ ipf^ fiteqatiyie Do JB fof Afert | 


* IB RiEspofisc 

Fjfi^ 


^IBReuiltsO^ 






be 


9 


Rulie‘PcH(l!v« ID Ri«{HJfK« to IB far Alert' did iu3t fire. E^lick en that flashing thin^ tocontfnuej 


Tntet«tiv*Rul*Map 
Kale ■-Q— 


4>; 


13 


I^BRewiteni 


I -IPiKiriyelDl^MegatiwflJfl^pgmelipJBfof Afartl 


' IB^Rcspoiisc^Watt 


^IB ReuihsHU 




j;U]BR«$ulbCiJ 




RutelB RfiSulU ?,l' dld rwt (hk. [dick en that flashing Ihina to continual 
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Kale Q- 


^labet 


G 


l_JIBR«ilttII] 


V ^ 


[ - 1 PiK^jy^ ipf^ fiteqatiyie Do JB fof Afert | 


* IB RiEspofisc 

Fjfi^ 


^IBReuiltsO^ 






be 


9 


Rule IB RasuIU 0.3' dhd rwt fwa. [click on thait fiaihing thing to con Chiu e| 


Trttet«tiv*Rul*Map 
Kale ■-Q- 




I^PRewiteni 


I -IPiKiriyelDl^MegatiwIDflejpflMeloJBfof Afartl 


' 1B,RDpofisc_Wa(t 


^IBRsultsOJ 


I^PRctlUlOn 




Rule IB ResulU O.Z' did not Ihk. [dick on that f]aiding thing to conlinue| 
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Kale Q- 


^labet 


G 


l_JIBR«ilttII] 


V ^ 


[ - 1 PiK^jy^ ipf^ fiteqatiyie Do JB fof Afert | 


' IB RiEspofisc 

Fjfi^ 










9 


Rule IB RasuIU Q.l'dhd rwt (mvl [dick on than Haihing thing to ^ on tin ue| 


Trttet«tiv*Rul*Map 
Kale ■-Q- 




I^PRewiteni 


I -IPiKiriyelDl^MegatiwIDflejpflMeloJBfof Afartl 


' 1B,RDpofisc_Wa(t 




I^PBctlUlOn 




Rule IB RfiSulU 6' did not fire, (click on diet Hashing thing to continue] 
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Kale Q- 


^labet 


G 


l_JIBR«ilttII] 


V ^ 


[ - 1 PiK^jy^ ipf^ fiteqatiyie Do JB fof Afert | 


' IB RiEspofisc 

Fjfi^ 




IjjgHwomsI 
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Rule IB RasuIU cNd not lire, (click an that llashin^ thing to cantiniw] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 






IjJBHeKiftiOGj 


I^BRtsufa^ 


Y ^IBRaultsl 


•b RetuiTLlB.llesulti 


UBRenjIbOj] 


i^]PHBuli¥<l 








Rute IB Results 4' b in pto^ress. [click on that fleshing thing ta centinue[ 
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Kale Q- 


^labet 


G 


I^B Baultsa^j 


I^BRcufaal] 


^IB ItsultsB 




UlSRgulbOj] 


neliin^_IB_Resulti 

l■UPRB^]I^^Oll 


ZLl D Result □ 

l^ffiRgultsSl 


9 


Rule IB Result! 4' Imd. [click Dini that Hashing thing In ccmtinue] 


TntffKtivnRukMap 
Kale ■-Q- 








I^BRtsufa^ 


T IjjBBiKilttBl 


•k RetunOB.Ilesulti 


UffiRgubOj] 


1.11 PRcaits Oil 






Ruts IB Result! 3' did not fire, (click on that flashing thing to continue] 
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Kale Q - S label G 

1^1 ,_, 

I ,_, 




UlSRgulbOj] 


neliin^_IB_Resulti 


[■UERtaitiOil 




ZLl D ResulbC] 

|^BR«ultsS| 


9 


Rule IB ResulU 2" did not lire, (click an that llashin^ thing to cantinue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 






IjJBHeKiltiOGj 


I^BResufa^ 


T |jjBltiKite3| 


•k RetuiTLlB.llesulti 

Iheins/i^dfe 


UffiRgubOj] 










Rule IB Result! O' did not lire, (click on that llashing thing to continue] 
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Kale Q - S label G 

1^1 ,_, 

I ,_, 




UlSRgulbOj] 


neliin^_IB_Resulti 


[■UERtaitiOil 




IjJgBisuteDl 

|^BR«ultsS| 


9 


Rule IB ResulU O' did not lire, (click an that llashin^ thing to cantinue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 






IjJBHeKiltiOGj 


I^BResufa^ 


T |jjBltiKite3| 


•k RetuiTLlB.llesulti 

Iheins/i^dfe 


UffiRgubOj] 
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APPENDIX D. RULE TRACE OF MISUSE CASE PREVENTED 


The visual trace of the ruleset execution was used to show that the misuse 


highlighted by the Misuse Case and accounted for in the Security Use Case is prevented 


through the RuleML ruleset. This trace is completed using the following parameters: 


Type of query: 

Role / Actor: 

Location: 

Security Level: 

Alert Present: 

Alert Classification Level: 
Expected Result: 


Destination Port 

Harbormaster 

San Diego 

Unclassified 

True 

Secret 

“Vessel Results from Unclassified IB” with ID 
Injection for Port of San Diego” 


The expected result from this query and the RuleML execution is an IB response of 
“Vessel Results from Unclassified IB with ID Injection for Port of San Diego” to the 
user. The trace was completed using RuleManager’s Interactive Rule Map functionality. 
The pop-up boxes shown throughout the trace indicate the sourcing of predicates that 
would be included with tagged data in a live system. This was not replicated for this 
research and instead was manually inserted via the dialog boxes. 

For the rule trace shown and from the interactive rule map of RuleManager, 
various indicators are used to show the actions during the trace. A rule or variable 
highlighted in Yellow, indicates that a rule or variable is currently being sourced. A rule 
depicted in Red indicates that the rule did not fire (execute) from the ruleset. A rule 
shown highlighted in Green indicates that the rule did fire and the result of that firing is 
also shown in the green highlighted box with the predicate name. Pop-up dialog boxes 
shown in the trace indicate the sourcing of a variable or predicate that would be done by 
an external entity (service) or taken from XML attributes attached to the query upon 
origination (i.e., user role and user security level). 
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Kale Q- 

G^i 

I 


^labet 


0 




JUEGR^tultsJ 


% itrtiiniJl&-“* 


^IB ReuilbOJ 


^IB RttuthJ-l 


jSlie ResvltaOJ 


Shew > 

1 TerniVelu* 

' Reid Teme 
R«d All Vahid 

SIS'SmuSOJ 


^ISRdulbS 


Trttet«tiv*R«l*Map 


Mi 


^IG Results & 
^ Alcft NeftKFcatiDH ii Absent 


J^IS Rduitf 0-1 


^Queiy is Valid 


■ VaUJiuery ^ierhuUsS 


gj IB Results 


Posittm S> Respoflu to f« Alert 


^IBResuItiOJ 


^ IB Results 3 ^ hegaitive D Response to IB for Alert 

^ Query Invalid 




Term 'Valid^Query' Soutxed. [clkk on EhaE flashing thing to continue] 
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Kale Q- 

Q9\ 

I 


^ labet 


0 


__ quCfy ii iiivi^ld 

^ □JQui ylrtvallni 

^ Qakland l-hrt>Drma5tef quEiy is valid efestinatkon 2 

^ Quay ■$ Valid 




^ SO Hartjomustef quciy is valid ofigination 

- HM^VdSd.Qymy 


jal so HartwiTwsrte qu«y e valid cf«tlft«tton 


Oakland Hartannastcr qu«y is valid dcstmatjon 


jilOaltland qwey is valid origination J 


f n u qgcty ii valid onqi nation 2 

•Ji OaUand Hpd^rfnastSf goOfy 4 valid onginglion 




Term 'KM.Valid.'Queiy'' Sourced, fclkk on that fladhinq thing’to continue] 


Tntet«tiveHyl*Map 




^ Oakland KarbormaStir query is valid destination 


Alert Dak Secret IQ. 

^AlHtSOSecretlEZ 


i3i EWO quwy ij invalid 
^ SD Havboimaater query is valid desbnatinn 1 ^ SO S«f«t IB 


^Oaktand r,rr— 

^ OaUand Ha^tionnestef que^ is valid daftination 1 


:^S0 Her^rmattet qw«y itvi^id destination 




^ EWO query is valid 


^ SO hlartrorrnaster qutiy is valid otiginalion 2 ]B 2 


Alert SO TS IB 2 


□d SO HartKirmaiter query is valid aiiginatiEin 


Alert OakTSIQ 

^ Oil(tpnd Hadsoimastcr query is vabd origination 2 


EWO query is valid 2 

^ Alert 0ekTSIS2 




Term 'Usef_lto[e' Sourced, (click on that flashing thing Do continue] 
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scale ■-Q- 


Mi 
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Kale Q- 

G»i 

I 


^ labet 


0 


^ QuHyInvBidI Oakland Harbcmnader quety is vaQd destinatian 2 

:3l OiWirtCt Herb*ffflistet qw«^ a velid origineliofi ^ Oakland Herbomiaiter query is valid deit-nation 




^ H M quay i s invaltd | . 




^ SO Naifadnviaster qv^ 4 valid destination 2 


JilSD Herhomastaf query r/alld^d'^neti^"''*"'^'^ “ ^ que^S v-W odginabonl 


Que^ is Valid 

^ SO HerbonnaEtaf query is va^id □nginalion 




Term 'Usef ttD[e' Sour^edL (click on that (lashing thing Id continue] 
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Kate 0 -Slabet 0 


c»j 

^ ' JjJ QutQr 1 ^ 0«y and HirbtrmiJter iqy«(yi*v9licid«t>tl*tion2 

aJ Oalcland Haibormaittr quay is vil'pd wiqmatisn ^ Haibomwitw quay is valid d«ti w!»n 






SC' IHttbomufta quay invalid datination _ 


^SO Harbunnasta qucfy is valid destination 2 


;3J Oiidand HaFtwnnasta quay is valid origination 2 


I ^ SD HaifaomMfla quay is valid ongwation 2 \ 


^Quefy is Valid 

^ SO Harbormaita quay is valid arigiitation 




Rute‘SO Narbomuita quay is valid isrfginatidn 2' did not fiw. [click on that flashing thirty to continue^ 
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Trttet«tiv#fUil*Map 
Kale Q 


^labet 


The Harbormaster Query Type window opens 


Mut li ihs vrfue d( HW.QuetiH 

Solod avAjc 

19;, Onflunitin^Rort Ouery 

I Dnlinaliao Port Quay I 


i valid originalien 2 


Select the Destination_Port Queiy radio biJtton 


|. Dffitfcng* ] [ jjjiply I [, Canwi 


¥mm 


qu«y is vihd deiWiitiDn 
>rm* st<f qmiy i t valid anqinrtioft 




Trttet«tiv*H«l*Map 

“:■*« •- 5 - - Bhbet -- 0 
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Kale 0 -S label 


I 

<T>I 


G 


[_JSDH*rl?IKm«tefqueryqvtfdOfiQift|itt<>n2l 

^ Oakland Karli«rmaEtef quefy is valid originalien 2 
Oihlind HiiboFmaitcf quefysvilNl deitinilnn 




^ HM_Qucri« 

Obey 

^ Oakland Harfacrmaster queiy ii valid oriqinalion ^ SD HarboniiaTter qucty is vihd deiWiitiDn 

I "i SD Hirtwfminitti gutw it valid ariainationl 
^ OfiWand MiitoiniMief quesyii valid de^bnaiionl 

^ £D Harbonnaster quety « vald destinatiEin 2 




Rule‘SO NarbormaitH queiy ia valid JsrfgitratTDfi' did ncrtfire. (click cm that fiashrng thing EaconCinuel 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


ETs^ 


^ Poli^ DcCetidn Point 2 
J!l Oakland Harbormaster quety is valid destination 

^ EWO query is valid 

^Oakland KerbormaSter query is valid onginatiDn 2 

^ Oakland HaebonTLaftef qutiy ts valid destination 2 


- PpP.pccU» 

^ SD Harbormaster quety is valid destination 

I jJ 50 Harborngutcf query it valid ongination Z I 


:3l Polity Decision Po^ 


jJ EWO query it valid 2 


SO Naibormastcr query is vali d destiiMlioft 2 j 
dii Oakland hlarbormaster query it valid origination 


Term 'P[P_DecisjDn' SouncecL (click chi that flashing thing to continue] 
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Tntet«tiviefUil*Map 




j:s f Policy Oecwn Point 2 



Click the Apply button 
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Kale Q- 


o; 


^labet 


0 


I Jj Poftcy Dwbiorv Pointt^ 




^ Policy DEciiion Point 


^ UHr„Rote,Pflnnii^i«ls 
TlttJE 


9 


Rute'Policy Deciaion Point 2' dkl notiifev [click on thart Hashing thin^ to continue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


lilJ Policy Ocdsion Point 21 


j] PoCcy Decision Po^ 


jaOaMwd Hafbonrhistef qu«ty it valid destinition 

I ^ SO Harfaonnaslief queiy « valid prigntion [SO HubOnnattCf qutfy it volwl oriqaftation 21 


^EWO quc<y ii valid 


PDP_DwM«i 


ni l SO Hartaocma^ter queiy is vaEd deslimailicin 


Oakland HarbormBitcf qutty is valid destinalwn 2 


SO HaifaotmastBr queiy is valid destinatipn 2 I A 

^ Oakland MartKinnaster queiy is valid origination 

^ EWO queiy is valid 2 

^ Oakland Haiboimaster queiy b valid origination 2 




Rule 'Policy Decision Point' b in proqioss. [cEck on that flashing thing to continue]! 
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TAtet«tiv*JUil*Map 
Kale Q 


^labet 


I 


I ^ Poii^ Dgciaiofi Point | 


l-iJPolicvOftCT«ortPoint 2 i 
i3l0aM*fid H((b<irmjistef queiy itvilid dtstirnti^ri 
I^SD HartianwiftsljerquayiivjgijowwMBiiiiilSDHulwimMta^aiWittflM orighlUiOflll 


^ucty ii viJ 


fGfJimdAKi 

Tjt» 


Hi so HafbflnnaftiLr quay invalid destinalicn 


^ Dihland Narbotmaitcf queiy is valid dntiruinn I 


!^S0 hUibcrcnaiteryuBQ^isvaM deat inatjo n2 i 

^ Oakland Hairbrnmaaler quay is valid ori^natian 

^ EWO qu«y is valid 2 

^ Oakland Harbfjrmaslcf queiy is valid wiginaticin^ 




Rule 'Policy Decision Point' fmd. {clfck on that llaslnin^ thing to continue] 


Tntet«tiv*ltul*Msp 
Kale ■-Q- 


^ ^ HarbonnaStcr qucty is valid destination 
^Oakland Harbofm«fcr quety it valid origination 


::dCftieiv Invalid. 


^ Oakland Haiboimaster queiy is varid deitinabon 


- HM JUy_Qu«y 

Jiije 


^ SD HaiboniMster q ueiy B valid destin ation it 


Query is Valid 


IjLTSOHaifagninwiefQmfviivaWofii^aiaooJl 


.:2l Oakland Hafboffnaitfltquefy if vfliid destination 2 

IjJSOHatboimesttfOuCfy ifvilidoriainrtponl 
EJWi^oueivhlovaiidl 




Rule 'Policy Decision Point' tited. (click on that flashing thing to continue] 
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TAtet«tiv*JUil*Map 
Kale Q 


I 


^ labet 


-aJAIntniiirT^tlt 

Oakland Harbermadcr quciy ii valid! Qrlginatiofi 


:'3l OaUofid Hafbormaitff qvety it vflld onglnaliO'^ a 

:ill6 

l-:JSOHitboffftKteraii«yiitv>iid o<iQi*mioft 2 l 


^1 Oakland Narbotvnacttr quciy is vaKd d«|ii^alion 2 


^ Oakland Harbormaster query ii vahd destination 


^Est Location for Robe 


_Tl Alert 50 IS® 2 


I^SO Hafbwmastef query«¥alidpiTgit>atiwi| 

J 3 J Alert Oak 5 «rflt IB 2 


I^VResulUU' 


SO HaibcimKttf OMiy is valid destinatiDn 2 
^AIe.tS0S«ret®2 ' 


iHi SO hhibormaitef query b valid d^ination 




Rube 'Policy Deciaion Point' fmd. {elfck on that llaslnin^ thing to continue] 


Tnter«tiv*Ryl*MBp 
Kale ■-Q- 


^ IB Reauhi 0 

^IB Rsi 4 t $4 

^ Alert Oeb Secret IB 2 ^®RjesultsOJ 

J!il £W 0 query is valid 

^ Alert SO Secret IB 

^ Alert OafcTSIB 

: 31 IB RwuJts 02 ^ 1 ® Alert SO Scc«t IB 2 


^Aicrt Oak Secret IB 


JSIAI^SOTSIBJ 


::3J]BRcsulti 3 
I -U SO HartiwmaslieT query ii valid ofkjinatmi | R 


% liberjSecuflt^r.l-eyd! 


^Oakland Harfanrfoastef query ii valid destination destination 2 


|:JSOHarfaom.^>w^^wjq 


Oakland KertaormaEtN 


laEtN qr>ery is valid aiigirul»n 2 


^ SO Harbonnaster query is valid destinatiors ^ _ 

lOJ SO HgrfaoimB flg ttuery g valid deflimtion I • 

I ^ ^ IS 2 

^Oakland Harfaormasler query is vaEd eriainatjan 

jjieriHiKjni 




Temt 'User_Secunty_Level' SourcedL (click on that (lashing thing to continue] 
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Ksle Q 


I 




^EWO query is valid 


^ IB Reiutts Oi IB Rejulti i 


Jli Alert Oai: Set:ret S 


^AteftSDSecfetieZ 


jaAkrtSOSecfet IE 

^^Eft OahTSte 


'' ' f/ 


^Alcrt^OTSlSJ. 


^ IB Rtsults 3 ^ 

|_Ll5PHflifapimast<f queiyis'iwMflrigiiiali^ ■ 


^ OarklarMl Hadiannaster query tsvafid destmaticin 

^ uairuna lidrQafmKier query rs valid destinatjon Z 


I HarbrNm^af r^ucry is valid origination 2 

Htiibcrmatttv qiit^ it valid dertirvatBOti _ 

SPHar bofm art g q uery i; v^id de^rtatjon 2 . 

^ffito5uits2 i| 


JJ Alert 0ahTSie2 


^Oadgnd Har^omiafttt query if valid ■unqinatiori 
Resub^ 




Term 'User_Security_Level' Sourced, [clrckon that flashingi thing to continue] 


Tntet«tiv*Rul*Map 
scale ■-Q- 


^EWD query is valid 


^ IB Results Oi j2l IB Resulti Z 


.^AhitSDSecfetlBZ 


^Alert SO Secret IB 

^ Alert OahTS 1 C 


Alert Oak Secret IB 


^ Alert SO TS IB 2 . 




|_JSPHaifapiinasterttMeiyi>v»Marigina|ipn| 


^ Oakland Hartiarmaster query is valid rtestmatiun 

^ uatoatH i-tarqamnKier query rs varid destination Z 


I ~i SD HartiCfn.j^ ^ Harbttrm^er query is valid origination 2 

l 3IS0 Hedwrrtiatttv query invalid destirNSttqn 

SOHarbofTnaaerqueiy is vrfid| de^nation Z . 


Alert 0ahTSEe2 


Oakland Harbomtaster query is valid onginatrori 
ResglUOJL 




Term 'User_Secunty_Lerel' Sourced, {click on that (lashing thirtg to continue] 
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Trttet«tiv#fUil*Map 
Kale Q 




^labet 
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Kale Q- 




^labet 


0 


^Oaktand Hartaarmaster query ii vaEd dslinatian 




^ SD Harb^ntiffter queiy d valid dcftiiriatidn 


% Vcf9«l_0eflinailKfii_pDrt 
J3yj Jugj 


^ OaldamI HarbormKtcr query rs vaEd dcsDna/tian 1 


Jjj SO Harti o >m>ftef v^M d«tirtrt> ort 2' 




Term 'Usef Secuiity L»el' Sourced, [clkkon that flashingi thing to continue'] 
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Kale Q- 




^labet 


0 


^Oaktand Hartaarmaster query ii vaEd dslinatian 




l-JSDHiifaofmastcfduciy it valid 


% Vcf9«l_0eflinailKfii_pDrt 


^ OaldamI HarbormKtcr query rs vaEd dcsDna/tian 1 


IjU so H«botmtttef cww it vaM dcftpftrtioft ^ 


9 


Rule‘SD Narbomiaitef queiy it valid destrnaticn' did nuA fire, [click tm that n«hiiig thinq tncontirvu^ 


Tntet«tiv*Rul*Map 
Kale ■-Q— 




1^1 


^ OoklaEvd Harbofmoster query ii vaEd dstinatian 


j_jSDHi>bofrtmtefdue«yitvalid dtitiftationi 


t V«Hi_[>«tkHtlai^_Port 

Smpege 


^ Oakland HarbcHtnatter query rs vaEd desbnOtian 2 




Rule ‘Oakland Harbormaster query is valid onqinatfen 2' diid nut fire, [click on that flashirtq Ihinq to continue] 
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Kale Q- 




^labet 


0 


^Oaktand Hartaarmaster query ii vaEd dslinatian 




l-JSDHiifaofmastcfduciy it valid 


% Vcf9«l_0eflinailKfii_pDrt 


^ OaldamI HarbormKtcr query rs vaEd dcsDna/tian 1 


IjU so H«botmtttef cww it vaM dcftpftrtioft ^ 


9 


Rulie‘Oakiond Herbormester query is valid anqirutffM^' did not fire, {clkk ehi that Eeshtr^g tiring tocDnCfnue] 
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Kale Q- 




^labet 


G 


I _J Oakland Harfaoimastef quay « valid destination | 




l JSDHi>faofm>stefqiiciy it valid 


% Vcf9«l_0eflinailKfii_pDrt 


I ^ Oildand Hartwinnastef quay ti valid derfjrmjon 2 . \ 


IjU so H«botmtttef cww it vaM dcftpftrtior^ 


9 


Rulie‘Oakiond HarbonuMstef qu«y is valid dstinaition' did not fine, [click on thatfiashing thing tocontiivuej 


Tntet«tiv*Hul*Map 
Kale ■-Q— 




i^i 


fWO query it valid 


Invalid ] 


.31 £WO queiy » valid i 

- EWO.y.M_Qii^ 


^ EWO quay is invalid 


:aj Queiyij Valid 




Term 'EWO_Va]id_Q\>«y' Sourced, [dick on that fTashmg thing to continue] 
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Kale Q- 




^labet 


0 


J3IGW0 query is 


^ B^O queiy b valkl 


[ 

■[ 


■ EWO Vdd 




EW^.S^_5 ™tdj j; i, v.lid 


9 


RuEe'EWO query bin valid" lain p^reai. [click nnithat ffiasding thing to continue] 


Tntet«tiv*Hul*Map 
Kale ■-Q— 


Diabet 




1^1 


OJ BMO quEfyb valid 




JH GWO query b vdid 2 


■ EWO Vdd queer 


1.:;^ EWO quieiy b irwilidj 


^Queiyii Valid 




Rule‘EWO query b invalid' Fired, [click on that Flashing thing Do continue] 
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Kale ij 

O 


^labet 


i^EW0flUMyitvriid2l 


^ EWO quef^ b valid 


I 

I 


■ EWO Vdd qucfy 




j;quoyi,V.lid 


9 


RuEe'EWO qusy b valid 2' did iwtfira [click on that llaihing tfiiivg to continue] 


Trttet«tiv*fUil*Map 
Kale ■-Q— 


c^\ 


^3 


1^ EWQ quefy b valid [ 


[■iSlQiinjy hvtM i 


i^EWOfluwitvalld2l 

■ mo VddQH^ 

Falff 






Rule'EWO qu«y b valicf did not fine, [click ofi Chat tlaalungf thing to continue] 
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TAtet«tiv*JUil*Map 
Kale Q 


I 


^ labet 


^Postl^ [D RespaiiH te EB F«sf Alert 


i3l Alert NolifiulfQn ij Abunt 




- V^,Qu«T 


ZUIBRetuteO-S 


ij Query ii Valid 


^ B REiults O' 

^ 16 Bcsulk 5 


^ Negative ID Response to IB far Alert 




RuEe'EWO query Is ^aliff did not fire, fclkk on Ehat flashing thi^g to cuntintw] 


Tntet«tiv*ltul*Map 
Kale ■-Q- 


i^lBReurltiDJ 

JiJPQStlrve ID Rexpanie te IB for Aert 


BeduitsO,? 

i3l Alert Nolificalfan is Absent 


[jjjQMWlnvaWl 


- V^.Ch*«T 


ZllIBRttgllsOJ 


^ Query ii VaBd 


i^l 6 BcsuttsOi 

,^16 B«ufts5 


Negalhre ID Response to IB far Alert 




Rule'Query Invalid' fired, [click on that Fleshfitg diin^ to continue] 
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Trttet«tiv#fUil*Map 
Kale Q 

q; 


^labet 




^Postl^ [D Respanie te IB fof Alert 


i.’al Alert Nolifiulian ij AlKent 


[jJQMWinvjidI 




' VdM.C|ii«r 

JiVS 


ZklIERttgteO-2 


[^QtJgylaVaidl 


^16 ItciifttsOi 

^ 16 PhuH; 5 


^ Negative ID Response to IB far Alert 


9 


Rule'Query if Valitf is; in progresa. [click on ttiat flashing thing to CDnUnue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


L^JIBReurltiCJ 

i^PosilAre ID Rexpanie te IB for Aert 

^BReHfeiH 


:^ie P«utts0-6 

i3l Alert Matificatfen is AlKent 


■[ " V 


[ jigMCfylnvaBdl 


JiVS 


JliJlERttgteOJ 


I^QueryttVaidj 


^16 RcsuttsOi 

^16 Results 5 


Negalhre ID Response to IB far Alert 




Rule 'Query is Valid' fired, [click on that flashing thing to- continue] 
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Kale Q- 




^labet 


0 




□J PoutivE 10 Response to IB for AJeit 


^ hicqativc 10 Response to E6 for Alert 


' Ifi JlGlfWlltC_WBt ' 


^ IB Resjufti 0.2 


I 


.:JIB ResiAifU 


l^lBR«uHs:2J| 




Term lfl._Response_Wait' Sourced, [click on that fTeshrn^ thing to continue] 


Tntet«tivie Rule Map 
Kale ■-Q— 


Diabet 




i^i 


^ Alest Nolifitalion is Ah^nt 


^ Positive 10 Response lo ^ for Alert 


* Quny_Reqiii«i_{>itaJbii«rtkin 


Alert NotificatiDn is Present 


' ^KeqtweP BesjwnsetolSfprAlertj 




Term 'Queiy_RecEuire^DetBjnsertiDn' Sourced, [clicic on that flashing Hung to continue] 
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Kale Q 

q; 


^labet 


^ Aliit Motificetion is ^ 


^ Alert SO Secret IB 

^Nd AlstlB 


^ AlEft Oak Securt IS 


' Mert^PrcsentJle^ioiise 


^ Alert Oak: Secret t6 1 


^ Akft ^IctifKatiofi n- Present 


:3lA]ertSOTSIlB2 


^ Alert SO Se«et If ^ ^ Loealion 




Term 'Alert.Pfesent^Response' Serumed. [dick on tfuit fleshing thing E9 contfnue] 


Tntet«tiv*Pul*Map 
Kale ■-Q- 


;3J Alert Oak Secrritt-^ **®*tS® 


^^tB Rcute Zi! 

^ Alert OekTS IB 


^ Alert so ts IB J 


^ Alert hfot Valid fer Rele Lecalicn 




^ Alert Oek Secret IB 2 


:SiAlertOakTStS2 


iISllB ResciltiOJ 


^Alert SO Secret IB 


J^ie RtstAfOJ. 


^ IS RtiurtS ftS f^Ho AtertlH 


Term 'Alert^Notffrcalfon' ScrtjrceeL [dick on that flashiingthmg to continue] 
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Trttet«tiv#fUil*Map 
Kale Q 


^labet 


Oak SKrrtH^ ^^O TSJB 


^^ISRjesulbMi JIl Alert W<rt Valid f^r Hdle Lflcalion 

--' ^A]ErtBOTSlB2 


■fc M^JKotiflcrifan 

> , I " 


^ Alert Oak Secret IB 2 


^AIertOabT$[B2 


Qi IE Rsulti 02 


^AJift SO Secret lE 


J^ie R«(Af04 


JSlIE R«olts0-3 ^MnAlertB 




Term 'Aleit^rJotE^catiDri' Sourced, [click on that Hashing thmg to continue] 


Tntetaitiv*Rul*Msp 
Kale ■-Q- 


.□I Alert Oak Secret K ^ ^0 JS JB 


^ IS Results 21 i ^ Al«* Wtf Valid lor Hole Location 

-' 2ii Alert SOTS IB 2 


% Alnt JttutiflallDn 


^ Alert Oak Secret ]B 2 


^ ^ “ ZSlAlertOatTSBi 

iSl IB Results 02 


Hi AlHt SO Secret IB 


Hi IB RtstAfOl 


Hi IB Raults 0-3 ^MoAlertB 




Term 'Alert^Notrfication' Sourced, [click on that Oashiingthiog to continue] 
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Trttet«tiv#fUil*Map 
Kale Q 




^labet 



Trttet«tiv*Hul*Map 
Kale ■-Q- 


ail I 


I Set Vriur^rlcnn i 


Whvt li the vrfue ol j^wt^NslilketHn 
SalodevAjo 

^ 4JHt ExhEi (SECf^ IB] ^ Pcit of Oildind 
O AlHt Bdata fTS IB) fer Pixl of OaldHid 
# Aiait Smti (SECRET iB) t» PM ^ Ssa tHw 
O Alert EkhEi (TS IB] Icr Port erf San Ebego 
0 AIM &i4t« (SECRET IB) PM of l« Angeles 
0 Alert Esia (TS IB) Icr PM dl Loe Ai^ei 
0 HaAJMBttab 




Term 'Aler^NoIrfrcatron' ScrijnceeL [click on that fla&hiingthmq to continue] 
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Kale Q- 




^labet 


0 


^AlEit Oak Secrrta^ ^^O TSJB 


^AlntOakTSIB 


^AIertBOTSlB2 

‘ I 


jli AleA Valid f«r Aela Location 


% Akrt^Koliflattiiti 


^Al«t Oak Secret ]B 2 


^AIeitOabT$[B2 




OiAlift SO Secret IB 


:ilie R«cAf04 


JSl IB IlMolti 0.3 [^ Mo Alert Bj 




9 


Rule ‘Md Alert IB' dtd rvot lire, [click on thart Flashing tihin^ to cnniinuel 


Tntetaitiv* Rule Map 

Kale ■-Q- 


^AJert Oak Siirei K ^ **nt 50 TS JB 


IS Resulfa 21 i 

^ Alert OakTS IB 


^AIertSDTSlB2 


jli Alert. M <4 Valid for Hnle Location 


^ Akti^KotHkattmi 


^ Alert Oak Secret ]B 2 


IUAIertOakT 51 B 2 l 


iial IB Results 02 


Hi Alert SO Secret IB 


Hlie R«(Atf04 


Hi IE RMHiti 0-3 [HiMlo Alert i] 




Rule 'Alert OaJcTS IB 2' did not File, [click an that flashing dung to ccmtimie[ 
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Kale Q- 




^labet 


0 


^ AlEft Oak Secraa^ ^^O TSJB 


^^IS WesuitaMi 

l^fllertQjfcTSiBl 


^AIertBOTSlB2 


jli Akft V«Nd fijir Hiflie Location 


% Akrt^Koliflattiiti 


^Al«t Oak Secret ]B 2 


lUAIgtCmfcTSIBZl 




Oi Alert SO Secret IB 


:ilie R«cAf04 


JSl IB IlMolti 0.3 [^ Mo Alert Bj 




9 


Rule ‘Alert OakTS IB‘ did FMrt fire, [click on that flashing thir^g to contifiue] 


Tntet«tiv*Rul*Map 
Kale ■-Q— 


(^i 


13 


^AJert Oak Siirei 5 ^ **nt 50 TS JB 


IS Resulfa 21 i 
|:JAIertQjfcTSB| 


^AIertSOTSlB2 


jli Alert M<4 Valid for Hnle Location 


^ Akti^totHkattmi 


IjLJAIertOakSegetlBZ] 


[UAIertOakT51B2l 


lSIIB Results 02 


Hi Alert SO Secret IB 


Hlie R«(Atf04 


Hi IE RMHiti 0-3 [HiMlo Alert i] 




Rule'Alert Oak Secret EE 2' did not fire, [click on that flashing thing to conlinuej 


349 




































TAtet«tiv#fUil*Map 
Kale Q 

q; 


^labet 


Alert OifcSecwHl^ ^'*^TS IB 


s^lS WKuitaMi 

l^fllertQjfcTSiBl 


^AIertB0TSlB2 

‘ I 


jli Alert Valid f«r Aele Location 


^ Akrt^Koliflattiiti 


|^AIertOaltS«jetlB2] 


lUAIertOaMSIBBl 




^Alert^ Secret IB 


:ilie R«cAf04 


JSl |G IlMolti 0.3 [^ Mo Alert Bj 




9 


Rule‘Alert Oalc Secret EB' did not Flee fclkk on Chat naslun^ thmg to continue] 


Tntetactiv* Rule Map 

Kale ■-Q— 


(^i 


13 


Alert Oat SecietJ^ ^'^^ TS IB 


IS Results 21 i 
|:JAIertQafcTSB| 


|^AIertSDtSB2| 


jlJ Alert Mot Valid for Hola Location 


^ Akti^KotHkattmi 

JVM mts utupt 


Ij^JAIertOakSemtlBZ] 


[UAIertOaM51B2| 


Lal3ERe3u1ti02 


4ii Alert SO Secret IB 


J^ie R«(Af04 


^ IB Raufti 0.3 [^ Mo Alert i] 




Rule'Alert SDISIB 2' did not fire, (click on that na&tijngthmg to continue] 
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TAtet«tiv#fUil*Map 
Kale Q 

q; 


^labet 


[^fllMtOafcSecKtB^^^ertSDTSIBl 


s^lS WKuitaMi 

l^fllertQjfcTSiBl 


[^AIatSDTSB2| 


jli AleA V«Nd fijir Hiflie Location 


^ Akrt^Koliflattiiti 


|^AIeitOjltS«jetlB2] 


lUAIgtCmMSIBZl 




Secret IB 


:ilie R«cAf04 


JSl IB IlMolti 0.3 [^ Mo Alert Bj 




9 


Rule ‘Alert SD1S IB' drd rwt Iha. [cNch on that flashing Ihln^ to conefivue|[ 


Trttet«tiv* Rule Map 
Kale ■-Q— 


(^i 




I^MatOtS^^AkflSOTSBl 


IS Results 21 i 
|:JAIertQafcTSB| 


[^AIertSDtSB2| 


jlJ Alert. Mot Valid for Hole Location 


^IBRciuttsO 

|jllAtertSOS«wtB2l 


^ Akrt^Koliflsattiiti 


IjLJAIertOaltSeeKtIBZ] 


[UAIertOaM51B2| 


LallEResultiOJ 


4li Alert SO Secret B 


J^ie R«(Af04 


^ IB RmhHi 0.3 [^ Mo Alert i] 




Rule 'Alert SD Secret IB 2' did not file, {click on that flashlngi thing to continue] 
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Kale Q- 




^labet 


0 




Hi AlHt Mat Valid^ far Rate Location 


jjjAfeitSOTSIEZl 


I^At«ft0iteS*a«Le2l 



I^AIcitOd(TSB2l 


f 


A 


Alert SO T5I&I 



j 



■ Alerl,Present,Response 

I^AkrtOakTSIBl 




' ^ Alert KotifKation is Absent j 




i Jll Alert SpS«fttB' 




er 

< 




l:JAlertS0SKieLS2| 

IjJ Alert OffcSectetBl 


Ol Alert NoliricaliDn is Piesent 


[^hfo Alert ii] 


9 


Rule ‘Alert SD SKret IB' ia in pragiHS, fclkk on that (lashing thing to ccintinue] 
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Kale Q- 

G»| 

I 


^labet 


G 


r-UAtBtOi»tS*a«tB2 

I^AItrtOaitTSB2l 


Zi Aiqt Hot VaM for Rote lacation] 

j:JAi«tSOTSIEZ| 


I^AfptSOTSBl 


Men, Preseni, Response 


I^MertOakfs^ 


AlertKotificatiDn is Absent! 


I^AtotSDSecmBl 


IJJAlwt OifcSecmBl 


|:JAIertS0S«:ietB2| 

qJ Alert NaliricaliDn « Pieseot 


be 




Rule‘Alert Not Valid for Role Locatian’ did net fire, [click on that flashfog thin^ loconEinuel 
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Kale Q- 




^labet 


0 


IjlI AtetNrtaKJlwnliPfacnt i 

Aiert Hotficitipn h Absent | 

^ ID Rt^nu to IB for Alot I 

* Qvciy_R«qiiir«_Dato_li»eftkiii 

Tme 




^ Pofitivc ID Response to IB for Alert 


9 


Rute‘Alert Notificalnn Ii Present' b in pra^ress. [click on that flashing thing to continue] 


Tntet«tiv*Ryl*Map 

^ - 0 

(^i 

[jll Alert Nrtjftmion to IVa^ 

1^ Alert Notficibon h Absent] 

^ Mege^ IP Rep orBi to for Alert I 

" Qii«yJtegdm_{>»taJiisBrtkin 

Pwe 


Pofitivc ID Response to IB for Alert 




Rule'Alert NcriiFiceInn is Present' '^red. [click on that flashing thing to continue] 
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Kale Q- 




^labet 


G 




I Jll Atgt Naakafeon ta iVgcfH^ 

I^Aiert WotficitipnH Abicntl 

l-ZJ Weqativt ID Rmpohm to IB for A]«rt I 


* Qvciy_flrqiiir«_Data_lit»rticHi 

Tfue 


^ P^fitive ID Response tv ]3 for Ajcrt 


9 


Ryte'fie^tjve ID Response bo IB forAleff did not fire, fctickon that flashing thing to conlinuej 


Tntet«tiv*Ryl*Map 
Kale ■-Q- 




I 


Results 0:1 




' IB Ropoiisc Watt 

rfiJf 


^IB ResuttsO 

C BesdH^zil 

~iJ PoBtiwie P Re^HM W to P ^ Al^ i 




Rule ‘Positive ID Response to IB for Alert' is in progreas, [clkfi: on that (lashing thing to tontinuel 


355 

































Trttet«tiv#fUil*Map 
Kale Q 

q; 


^labet 


[ Jj N wiaive ID ItewKWK to IB for 4J^ 


liJIP FUfiult ^04 


' IB REsponsc Wait 

TfiJf 


IB Resjulti Q 

i lPBwdtaijl 

|■:^P^Mi^iwleP BespwiMtoBfOf Ahrt] 


9 


Rulie‘PcHitive ID Ri»pam«tD IB fc9f Alert' fired, fclkk on that flashingi thing to onntinue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 






I 




' IB Ropoiwe Witt 

rfiJf 


□ilBResuluO 

[UPRewift^jl 

|■::jp^^alivleP BesponsetoBforAhit] 




Rule IB RfiSulU rwt fiiK. [dick nn thait flashfng Ihin^ to conCinuel 
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Trttet«tiv#fUil*Map 
Kale Q 

q; 


^labet 


[ Jj N wiaive ID ItewKWK to IB for 4J^ 


liJIP FUfiult ^04 




^ IB REsponsc Wait 

TfiJf 


IB Resjulti 0 

[^BRewiteZlI 

|■::jP^«^liwleP BespwiatoBfOf Ahrt] 


9 


Rule IB RasuIU 0.3' dhd rwt Imk. [click on thait fiaihing thing to con Cm ue| 


Trttet«tiv*Rul*Map 
Kale ■-Q- 


^ IB Restit^ j^BBcjite^ 


Rewiucs .1 


li:JPR«utenl 


% Rotijnc_IB_Resulb 


iS iigRtKlteO-Zl 




Rule IB ResulU 0.2' ia m pfogma. [click on that na&hiing thiog to ccmtjnu«] 
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TAtet«tiv#fUil*Map 
Kale Q 

q; 


^labet 




IzJIBRtsuHt^ 


% Re1un^IB_R«ulb 

iJhdbtii/Sefi/e jS? lHAdbr/^. 




LS ugRtBiteO-zl 


9 


Rule IB RasuIU 0.2' ii tn pmgmE. (click on theE. Hashing thmg to ccmtinkw] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


^ IG Restit^ 


.: 3 Jia Rewiucs .1 


l::JIBRKutezII 


^ISRgultiS 


»fc Rpliim IB R«ttltt 

Khm^ Anutr Aw Chd)t$iilitd/e it4> ^ lugeflotr/br A 


LS iigRtKlte0.2l 




Rule IB ResulU 0.2' ia m ptcgma. (click on the! na&hiing thmg to cafltjnu«] 
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Kale Q- 

I 


^labet 


0 


^]B Rsulls€ 


;^3BRchiIIs J 


JjIIB ResultiJ 






■SJgRwuteOji 


■fe RelumJB^Resulb 

iJhdDtuiSedJBi^ i^ficaiffibrSa 


Ijqaiusufaoj] 


R«ultf 01 




RuEe IB RasuIU 0.2' ii tn pmgmE. (click on theE. Hashing thmg to ccmtinkw] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


|.:JIBRestJti2l| 




% RFEun^IBJRefutb 

tjhdbtaHKi/e £7 ifftesoffAfSt 




RHuItjOl 




RutelB ResulU 0.2' fitied. [click on that FlAshing diin^ (o continue] 
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Kale Q- 

I 


^labet 


0 


^]B Rsullsfi 


;^3BRchiIIs J 


JjIIB ResultiJ 








■fe Retun>_IBJRBfulb 

£1 i^ftcOitfArSa 


IjqaiUsufaOj] 


l_JIBR<MiteOll 


9 


Rule IB RasuIU Q.l"dhd rwt (mk. [click on thait fiaihing thing to con Chiu e| 


Trttet«tiv*Rul*Map 
Kale ■-Q- 


l^lPRwMln^ 


I^IBRestJtiZlI 




% RFtun^IBJRefutb 

tjhdbtaHKi/e £7 ifftesoffAfSt 




l_JIBRtMiteOll 




Rule IB RfiSulU 6' did not fire, (clicic on diet llashfng thing to continuo] 
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Kale Q- 

G»| 

I 


^labet 


G 


I^IPRqMtod 


Jjlie ResultiJ 




|^ERBtAi 2 l| 




■k Re1un>_IBJRBfulb 

Vimeffhfvtt^ tJheiuaefi/e ^ tHocBottfaeSa 


IjigiBIUsufaOj] 




9 


Rule IB RasuIU cNd not lire, (click an that llashin^ thing to cantiniw] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


|.^lPReiMH>^ 


I^IBBesultill 


I^IBReaJtiZlI 




■k RFtun^IBJResutb 

UHkHUW.^ it 4 > £7 tnoceo/tfseSt 


I Resulted 


l_JIBRtMiteOll 




RutelB Results 4' did notiire. (click on that llashfng thing to continLi«] 
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Kale Q- 

G»| 

I 


^labet 


G 






I^BRatAiU] 




■k Re 1 un^IB_R«ulb 

Uk^hMSk^^ ^ tHocBottfaeSa 


IjqaiUsufaOj] 


l_JIBR<MiteOll 


IRi 


9 


Rule IB RjsuIU 3' did not lire, [click an that flashing thing to cantiniw] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


|.^lPReiMH>^ 


I^IBBesultill 


I^IBReaJtiZlI 




■k Retun^IB^Resuhs 

UHkHUW.^ it4> £7 tnoceo/tfseSt 


I Resulted 


I—— T-n j_JIBRcsutoOll 

IjJB RcmIKZI '- ' 




Rule IB Result! T did not iire. [click on that llashfng thing to continLi«] 
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Kale Q- 

G»| 

I 


^labet 






I^BRatAiU] 




■k Re 1 un^IB_R«ulb 

^ tHocBottfaeSa 


IjqiBIUsufaOi] I^BRatifaQ l 

I _ —:—n GiBR« 5 teOn 

IJJB Betute^l '- ' 


IRi 


9 


Rule IB RasuIU O' did not lire, (click an that llashin^ thing to cantiniw] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


|.^lPReiMH>^ 


I^IBBesultill 


I^IBReaJtiZlI 




■k Retun^IB^Resuhs 

UHkHUW.^ it4> £7 tnoceo/tfseSt 


l^gResufaOil | ^PR«tittiO | 

I——i-n j_JISRc«i)tsOll 

IjJB RcMteZl '- ' 




Rule IB Result! O' did not fire, (click on that llashfng thing to continLi«] 


363 




























































Kale ij 

O 






I^IBRgutojI 




■k Retun^IB.Refuhs 

tJhduiMlBmtti ID UtoBonfarSt 


IjqiBIUsufaOi] I^BRgtifaQ l 

I _ —m GiBR« 5 te 0 n 

IJJB Bewte^l '- ' 


om 
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APPENDIX E. RULE TRACE OF OTHER QUERIES NOT 
SUPPORTED (INVALID QUERY) 


The visual trace of the ruleset execution was used to show non-support for actions 

that are not accounted for in the scenario and thus our ruleset. This is for items that are 

considered invalid by our security policy and should not return a valid result from the 

ruleset. This trace is completed using the following parameters: 

Type of query: Destination Port 

Role / Actor: Harbormaster 

Location: Shanghai 

Security Level: Lfnclassified 

Alert Present: False 

Alert Classification Level: Not Applicable 
Expected Result: “Invalid Query” 


The expected result from this query and the RuleML execution is an IB response of 
“Invalid Query” to the user. The trace was completed using RuleManager’s Interactive 
Rule Map functionality. The pop-up boxes shown throughout the trace indicate the 
sourcing of predicates that would be included with tagged data in a live system. This was 
not replicated for this research and instead was manually inserted via the dialog boxes. 

For the rule trace shown and from the interactive rule map of RuleManager, 
various indicators are used to show the actions during the trace. A rule or variable 
highlighted in Yellow, indicates that a rule or variable is currently being sourced. A rule 
depicted in Red indicates that the rule did not fire (execute) from the ruleset. A rule 
shown highlighted in Green indicates that the rule did fire and the result of that firing is 
also shown in the green highlighted box with the predicate name. Pop-up dialog boxes 
shown in the trace indicate the sourcing of a variable or predicate that would be done by 
an external entity (service) or taken from XML attributes attached to the query upon 
origination (i.e., user role and user security level). 


365 



KBte ■- Q — 

1 


^labet 


0 


^ IB Rcluitte G 

^ B Eilesults OJ 


^ S RjesuPts^l 


^16 




^ IB R«ulb Di^ 

^ IB Rtsutb 4 


' Hfiselve 
5 hci* 

; TtrmV'ilue 
i RjrtrtTefm 
' Re«S AIIVfllw» 
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Kste ij - ^ label 


^l^nyniVelKl 


ZU Megalive II 


^ Pesihive ID Response to IE for Alert 




^ Alert Ntrtilkfticin is Absent 


IjSt B FtgulaZl 

jJ ]& Betulh 0.1 JJ Queiy Invalid 




Term 'Velld^Quefy' Soutxed. [clkk on that Haskin^ thtng^ to cdfiitinue] 


[ntet«tiv*Rul*Mfip 
scale ■- 0 - 


^Oakland Harbermestef <|Ljeiy is valid destination ijvafid dette^BbOrtf 

■^Oatdand Harbormaster ^uety rt valid ori^lnaEfon 

SD Karbormaster que^ is valid onginilwn 

HM query is invalid 

" HM_Val^(^j«y h 

:□! SD Haibormast^ qtiery rt valid destination 


' ^ Query is VaEd 


isJ Oakland Haffcormaster qnery is valid ongination^ 


^ SO Harbormaster query is valid ori'’'" , i i • 

^ SO HaibormBstcr qiuny rS valid dcstinahor> i 


i^Qu qyliwalid l 




Term 'KM_Valid,Queiy'' Sourced, fclkk on that flashing lining to continue] 
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TAtet«tiv*JUil*Map 
Kale Q 


^ labet 


^Alcit Oak^ict IB 

^ Akit 50 StC^ri IB 2^ ® ^ JSl two ^uety it invitid 


^Alftft 50 TSJ®l 


^AleftSDSccfctlB 

^ 50 HiitHnTUtter qucfy Avalid on^m 


i3jl 5D hiaibornufter qu«y ^ valid originatian^ 


_ 5 J SO HarbormatKf niucfy if valid detlmatioit 2 
^Oakland Harbcmnattef query li valid arhgiPMthDn 2 


-HAl^ 04i;T5JB 2 


' JSJ HMouBV il invalid 

^Oakland Harfanrmuter query is validdestinatiem 

Oakland Harbormastar query is valid destination 2 

^ SO Harbunnaster query is vahd destination 


^ Atari OakT"^" 


Oakland Haibqnnaftef c^aty it valid origination 
^ Alert Oak Secret IB 2 




Term 'Usef_ltD[e' SourcedL (click on that (lashing thing Id continue] 


Tntetactiv*Hul*Map 
Kale ■-Q- 


T: 


^ Alert OakSeCiet IB 



iJ Oakland Haibonnaater qgary it valid origination 
^ Alert Oak Secret IB 2 
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TAtet«tiv*JUil*Map 
Kale Q 


^labet 


^ Oaltkand HaAoimasler queiy ii valid originafticin 


^ SO Hatbomusler queiy is valid 

HM is invalid I 


Ui JO H^o«n«nef gueiy ij valid eriginartism i 


HM QiwfT 


^Oaklaml Harbcxnnafter qgety is valid crigiinatiofi 2 


^ qLje 7 is VaEd 


^ Oakland Hartaaiinaslier quay is vaSd deslinatiQn 

; .:^Quaiy W ar>dj 

III SO Harfaeinnaster quay is vaEd erigination 

-l HarbertViKtW qu ^ Haibormastw qiwry is valid destinaSicn 2 




Terni 'Usef tl^[e' SourcedL (click on that (lashing thing Do centinue] 
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Kale Q-S label 

GH 

I 


0 


^ Oaltkand Haibannasler queiy ii valid originafticin 
I ^ SO Haifaflimastef quHy is vilid t^mwtinnJ 


~ |_jHMqiiMy a invalid J 

f-li Odkland Hartonnaistef guaiy is yiKd ofiginaltiiin 2 1 


|_ltSOHdifao«nwtefquwviivaBdQriqffatioo2l 


■ HM lUfaLQiwfy 

mt 


^ qLj <7 is VaEd 


I3l Oalcland Haffaoiinafler quay is vaSd deslination 


[:^QugyW>dl 

I Jj SO Haitiofmarstef quBy is vaid eriginaition | 

I ~l 5P HaftHHTT OltcToLi ^ Hartwimast w qiKfy is valid efestiFH[»n 1 


be 


9 


Rule ‘Oakland Harbormaster query is valid ori^inab'on 2 ' did not fire, [click on that flashing Ihing to ccmtinue] 
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scale ■-Q- 




|_J Oaldand HariMimaslief quay is valid originaticwil 


I ^ SD Hatfaanimter e|UH¥ g vM 


~ |.~iHMquBy is invalid J 

[■Ill Ortland Karbofmastrr quafy is vatd onqinaltiiin Z] 


[jLl so HjjfaownaaefQucfvw valid orioin4tion2] ^ 


HM.lMkLQiwfy 


I _I Oakland Hartaonnaattf tMCry g vaid itelwalion | 


^ qLJ€7 a VaEd 




I^SD Haifagmiagtef <||U<fygvaid originaitionl 

r 9**^”^*!que^ israltd dtstinatinn 3 1 




Rule‘Oakland Harbormaster query is valid deslsnation' did not fine, [click on fi^atfiashing thing tacsotiivue^ 
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Kale Q- 


^labet 


0 


^CunyuVulid 




:3lEW0 que^is Irtvralid 

■ EW0.Vaii4_Qii«y 




^ EWO quay is valid 2 


^ £WO qM«y is valid 




Temi 'EWO_VMid_QuBy' Sourced, [elicit nn that fTashtnj thing to continue] 


Tntet«tiv*Hul*Map 
Kale ■-Q— 


4 >; 




43lQiKfy»V^id 


~il FWO query is i nviBd 


' EWOVdUQiMty 

Fgift 




^ EVi^O queiy » veiid 2 


_iJ EWO quay is valid 




Rule ‘EWO query k invalid" is in progiess. [click nn that Hashing thing to continue] 
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Kale Q- 


^labet 


0 


QiKfy » V^id 




[^EWPqiMiytsTOjidl 


EWOV^Qiwiy 

I F 9 ift 




3l E^O ^tiy b vaFid 2 


^ EWO quay b valkl 


9 


RuEe'EWOqucfy bin valid* lired^ [click on that Eailiing thing to contmue] 


Tntet«tiv*H«l*Map 
Kale ■-Q— 


4 >; 


F 3 


4SlQiKfy»V^id 


[^CWOqLMiyBTOjidl 

!-^Qu^ Invalid I 

* EWO VdU Qimy 

Fgifif 


I ~J EWO QUMv b wM 2 [ 


_iJ EWO quay b veltd 




Rule‘EWO query b valid 2' did iwtfire, [cJicFcen that IFaihing thing to condnuej 
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Kale Q- 


^labet 


0 


QiKfy » V^id 




[^EWPqueiy is TOjidj 


' EWOVdUQiwfy 

F9ift 




I nl EWO autry it wM 1 1 


I^EWQ quaytsvalMll 


9 


RuEe'EWO qticfy H^aliff did not fine, fclkk on Chat flaslMn^ thmg to cnntinu#] 


Tntet«tiv*Hul*Map 
Kale ■-Q— 


4 >; 


^ Ntgrtivt ID Ras^rtte to- ]& fon Alwt 
^ Positive ID Response to IS for AJest 


^ ;^IBRBu)tsOi 


Results Cl J 


- VJM.Qii«r 


r. 


jj^Queiy Invalid I 

^l8Fl«uRs6 


^ <3iiany d Valid 


i3l Alert MolifiCition^rt Abien^ 2_j j 




Rule‘EWO query » valicf did not fine, [clkk ofi that nasliingf thing to cuntinue] 
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Kale Q- 

T‘ 

I 


^labet 


^ Ntgrtivt ]D R«^rtte to for Alwt 
^ Positive ID Response To IS for AJeit 


< IB Resits Oi 


Results CIJ 


- V^.Ch*«T 


' [^^eivlmilidl 


^ <3iiey Valid 


i3l Alert Molificett^rt Abjenj^ 2_j j 


be 


9 


Rule'<^efy Invalid' fined, [click on thst Fiashing thin^ to conUnuel 


Tntet«tiv*Ryl*MBp 
Kale ■-Q— 


4 >; 


^ Negative ]D Res^nte to IS fon Alert 
^ Positive ID Response To IB for Alert 


^ IB Results Oi 


Results Cl J 


- VJM.Qii«r 


^ .. 


InJQucsvIfwalidI 

jJBRwuRse 


l_JQuwvttValldl 


J3l Alert MolifiCition^rt Abienlj^ ^ 




Rule 'Queiy is Valid' did not fire, [click on Ifiat flaisltin^ thing ter continue] 
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Kale Q- 

T‘ 

I 


^labet 


^ Ntgrtivt ]D R«^rtte to for Alwt 
^ Positive ID Response To IS for AJeit 


< IB Resits Oi 


Results CIJ 


- V^.Ch*«T 


' [^^eivlmilidl 


I _J Quay it Valid I 


:3l Alert MoliJicat^itAtKyl^'^ 


be 


9 


Rule IB ResulU ?,l'dhd not Imk. [click on ait flashing thing to conCiinuel 


Tntet«tiv*Ryl*Map 
Kale ■-Q- 




^ Negative ]D Res^nte to IS foe Alert 
^ Positive ID Response to IB for Alert 


< IB Results Oi 


I^BBesuteQj] 


- VJM.Qii«r 




InJQuavIfrvalidl 

^I 8 Fl«uRs 6 


I _J Quay it Valid I 


^ Alert MoWicetie^A^enl^l 




Rute IB Resulli Q.3' did not ftre. [dick on that flashing thing to contiinue| 
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Kale Q- 

T‘ 

I 


^labet 


^ Ntgrtivt ]D Rw^nje to for Alwt 
^ Positive ID Response To IS for AJeit 

^ IB Resits Oi 


I^BBesuteOI 


- V^.Ch*«T 


[^Queivlnv^ 

^ISRetutee 


I _J Quay it Valid I 


:3l Alert MoliJicat^itAtKyl^'^ 




9 


RuEelB RosulU 0.2'did not Imk. [click on ait flashing thing to conCiinuel 


Tntet«tiv*Ryl*Map 
Kale ■-Q— 


4 >; 


I^BResuteOJl 

^ Negative ]D Res^nte to IS foe Alert 
^ Positive ID Response To IB for Alert 




I^BBesuteOj] 


- VJM.Qii«r 


^ .. 


InJQuavIfrvalidl 

^I8Fl«uRs6 


I _J Quay it Valid I 


^ Alert MoWicetie^A^enl^l 




RutelB Rfisulli 0.1'did not ftre. [dick on thait flashing thing to contiinue| 
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Kale Q 


Ml 


^labet 


dJlBResutm ^IBftHufts5 


l-iJBItodttni 


RflIiiniJB J 








I^JlBRewbOl] 


J31IQ ResultiO 


9 


Rule IB RasuIU 6' b tn pfogress. [cNch on that Bashing thing ta cenefivue|[ 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


m; 






*k RiB4iim_lB_ltflnftx 

iar^(3ueiyf 




Ugfatuteoil 




I^BfasuHsOl] 


OlIB ResultiO 




Rule IB RfiSulU 6' IwkL [clFck nn that flashing thing to continue] 
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Kale Q 


Ml 


^labet 


dJlBResutm 


l-iJBItodttni 


I RflIiiniJB.ltBHHx 








I^JlSRewbOl] 


::31IQ ResultiO 


9 


Rule IB RasuIU cNd not lire, (click an that flashing thing to cantinue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 


m; 


l^lSfiesuteil [^PfasuftsSj 




% RiB4iim_lB_ltflSiiftx 

imk/iHueiyf 




UgfatuteOll 






^|B Results 0 




Rule IB Results 4' did not fire, (click on that Hashing thing to continLie] 
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Kale Q- 


^labet 


G 




l-lJBItodtt2i1 


RrtunfJB.SBHiHx 

^IBRe£ufti2 _ 

EjBltes«Hj6| 


I^JlSRewbOl] 




::31IQ ResultiO 


9 


Rule IB RjsuIU 3' did not lire, [click an that flashing thing to cantinue] 


Tntet«tiv*Rul*Map 
Kale ■-Q- 




l^lSfiesuteil [^PfasuftsSj 




l-ZiBRputeF 


[:JPlteMJteI1 


% RiB4iim_lB_ltflsiiftx 

imk/iHueiyf 




UBfatuteOll 






^|B Results 0 




Rule IB Result! 2 " dyd not fire, (click on that llashing thing to continLie] 
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Kale ij 




I^PItodttEn 


^ V l:2il&Rpiltti3l 




I RrtunfJB.SBHiHx 








|:JlBSewteOl] 


i^PRewjftiOl 


9 


Rule IB RasuIU O' dUd not lire, (click on that Hashing thrf>g to continue] 


Tntet«tiv*f(ul*Map 
Kale ■-Q- 


4 >i 


I^BResuteil [^PB«iiits5j 






[:JPIteMjiiaI1 


RiB4iim_lB_ftBHltx 




UgfatuteOl] 




l^ffiRguHsOH 






f^telB ResulU O' did not tire, (click on that llashin^ thing to continue] 
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Krit ij 


O 




I^PItedtt2i1 / 

f IziiisRcdttal 


Rfl4iimJB_ftBHltx 

tHvVaUQiyf 

, 

[ijpitiist)ia6l 

EJffiSewteOJl 

i^PRewjftaOl 
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